Uncategorized

Microsoft seeks U-Boot Linux firmware Engineer

Senior Software Engineer, Linux Firmware – CSI / Azure – Cloud Server Infrastructure
The Cloud Server Infrastructure Firmware Development (CSI-FW) team is responsible for server hardware definition, design and development of Server and Rack Infrastructure engineering for Microsoft’s online services. […] This role will be for a highly-motivated Firmware Engineer with a solid background in embedded system design using embedded Linux. […] Required Qualifications:
[…]
* Extensive knowledge of u-boot customization, Linux kernel internals and adding new hardware drivers
[…]

https://careers.microsoft.com/jobdetails.aspx?jid=282596

 

Standard
Uncategorized

Docker: LinuxKit (and Cilium)

https://github.com/cilium/cilium

https://blog.docker.com/2017/04/introducing-linuxkit-container-os-toolkit/

 

 

 

 

 

 

Standard
Uncategorized

IBM updates Linux IMA to improve boot security

Thiago Jung Bauermann of IBM has submitted a 6-part patch to the Linux-IMA-devel/Linux-Kernel lists, with some improvements to Linux IMA for OpenPOWER secure/trusted boot. Including comments from parts 1 and 6 of the patch, see the full patch for full details.

Appended signatures support for IMA appraisal

On the OpenPOWER platform, secure boot and trusted boot are being implemented using IMA for taking measurements and verifying signatures. Since the kernel image on Power servers is an ELF binary, kernels are signed using the scripts/sign-file tool and thus use the same signature format as signed kernel modules. This patch series adds support in IMA for verifying those signatures. It adds flexibility to OpenPOWER secure boot, because it can boot kernels with the signature appended to them as well as kernels where the signature is stored in the IMA extended attribute. The first four patches are cleanups and improvements that can be taken independently from the others (and from each other as well). The last two are the ones actually focused on this feature. […] This patch introduces the appended_imasig keyword to the IMA policy syntax to specify that a given hook should expect the file to have the IMA signature appended to it. Here is how it can be used in a rule:

appraise func=KEXEC_KERNEL_CHECK appraise_type=appended_imasig
appraise func=KEXEC_KERNEL_CHECK appraise_type=appended_imasig|imasig

In the second form, IMA will accept either an appended signature or a signature stored in the extended attribute. In that case, it will first check whether there is an appended signature, and if not it will read it from the extended attribute. The format of the appended signature is the same used for signed kernel modules. This means that the file can be signed with the scripts/sign-file tool, with a command line such as this:

$ sign-file sha256 privkey_ima.pem x509_ima.der vmlinux

This code only works for files that are hashed from a memory buffer, not for files that are read from disk at the time of hash calculation. In other words, only hooks that use kernel_read_file can support appended signatures. The change in CONFIG_INTEGRITY_SIGNATURE to select CONFIG_KEYS instead of depending on it is to avoid a dependency recursion in CONFIG_IMA_APPRAISE_APPENDED_SIG, because CONFIG_MODULE_SIG_FORMAT selects CONFIG_KEYS and Kconfig complains that CONFIG_INTEGRITY_SIGNATURE depends on it.

https://lists.sourceforge.net/lists/listinfo/linux-ima-devel

Standard
Uncategorized

Background for Kernel Lockdown patch

Re: https://firmwaresecurity.com/2017/04/05/linux-kernel-lockdown-2/

Here’s more background on the Kernel Lockdown patch, from email by David Howells of Red Hat:

The idea is to properly implement UEFI Secure Boot mode such that we can kexec another operating system (Linux, Windows, etc.) and pass on the Secure Boot flag with a guarantee that we haven’t been compromised. This assumes the following:

 (1) Someone wanting to compromise your machine can’t get physical access to the running hardware.  I think pretty much all bets are off if someone gets their hands on your computer.
 (2) Whatever boots our kernel is not itself compromised.  If it is, there’s pretty much nothing we can do about it.
 (3) Whatever boots our kernel can prove that our kernel is what it says it is.

Now, (2) has to start with security right from the system booting, and likely involves the firmware being checked by the hardware.  The firmware then has to validate anything it runs, and the things it runs have to validate anything they run, etc. up to our kernel being booted.

With regard to (3), take the example of booting Fedora Linux on a UEFI PC in secure boot mode: the UEFI BIOS boots the Fedora SHIM, which boots Grub, which boots the kernel.  The SHIM is signed by the UEFI signing authority and is checked against the UEFI key database; Grub and the kernel are signed by a key built into the SHIM.

[Note that in secure boot mode, Grub loads the kernel image asks the SHIM to verify it; further, the SHIM will catch anyone trying to boot without verification and halt the machine.]

[Note that we do verification with cryptographic signatures, but compiled-in hash whitelists would also work.]

In order to maintain the security guarantee, the kernel then needs to prevent unauthorised modification of code and data in the running kernel (module loading is permissible) and also it needs to protect any private keys or other security data it may hold within the image.  We try to do this by the following means:

 (1) Refuse to use any key or hash that UEFI has in its blacklist.
 (2) Refuse to load any module that isn’t signed/hashed.
 (3) Refuse to load any firmware that isn’t signed/hashed.
 (4) Refuse to kexec any image that isn’t signed/hashed.
 (5) Refuse to dump a kernel image for software suspend/hibernation if it’s not encrypted.  Further, if it is encrypted, the key must be protected.
 (6) Refuse to load a dumped kernel image that isn’t encrypted with a protected key.
 (7) Refuse to allow userspace direct access to kernel memory (no /dev/mem,  /dev/kmem, /proc/kcore).
 (8) Refuse to allow userspace direct, unsupervised access to hardware (no iopl, /dev/ioports, MSRs, etc.).  It might be feasible to open PCI BARs through dedicated device files for certain functions though (eg. X servers), but unconstrained DMA must be disallowed.
 (9) Refuse to let userspace configure a driver to use a piece of hardware to muck around with system RAM, possibly by mismatching driver and device.

See the posting on the linux-kernel/efi list for full message.

Standard
Uncategorized

Linux Kernel: exclude EFI from KASLR VA space randomization

Greg Kroah-Hartman of the Linux Foundation submitted version 4.10 of a 81-part(!) patch to the Linux kernel by Baoquan He of Red Hat.

[PATCH 4.10 65/81] x86/mm/KASLR: Exclude EFI region from KASLR VA space randomization

4.10-stable review patch.  If anyone has any objections, please let me know.

commit a46f60d76004965e5669dbf3fc21ef3bc3632eb4 upstream.

Currently KASLR is enabled on three regions: the direct mapping of physical memory, vamlloc and vmemmap. However the EFI region is also mistakenly included for VA space randomization because of misusing EFI_VA_START macro and assuming EFI_VA_START < EFI_VA_END. (This breaks kexec and possibly other things that rely on stable addresses.) The EFI region is reserved for EFI runtime services virtual mapping which should not be included in KASLR ranges. In Documentation/x86/x86_64/mm.txt, we can see:

        ffffffef00000000 – fffffffeffffffff (=64 GB) EFI region mapping space

EFI uses the space from -4G to -64G thus EFI_VA_START > EFI_VA_END, Here EFI_VA_START = -4G, and EFI_VA_END = -64G. Changing EFI_VA_START to EFI_VA_END in mm/kaslr.c fixes this problem.

More info: see the linux-efi/linux-kernel list.

Standard
Uncategorized

Linux Kernel lockdown

David Howells of Red Hat has posted a 24-part patch to the Linux-(Kernel,EFI) lists, which hardens Linux from some firmware attacks.

These patches provide a facility by which a variety of avenues by which userspace can feasibly modify the running kernel image can be locked down. These include:
 (*) No unsigned modules and no modules for which can’t validate the signature.
 (*) No use of ioperm(), iopl() and no writing to /dev/port.
 (*) No writing to /dev/mem or /dev/kmem.
 (*) No hibernation.
 (*) Restrict PCI BAR access.
 (*) Restrict MSR access.
 (*) No kexec_load().
 (*) Certain ACPI restrictions.
 (*) Restrict debugfs interface to ASUS WMI.

The lock-down can be configured to be triggered by the EFI secure boot status, provided the shim isn’t insecure.  The lock-down can be lifted by typing SysRq+x on a keyboard attached to the system.[…]

See the full patch for more info:

http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=efi-lockdown
http://vger.kernel.org/majordomo-info.html

Standard