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.