Secure Boot Breaks Kexec, Hibernate Support On Linux

A set of "controversial" patches were published by Matthew Garrett this morning for the Linux kernel. One of the patch series will disable the kernel's support for kexec and hibernate support when running in a UEFI Secure Boot environment.

Hibernation power management support needs to be disabled since right now the Linux kernel has no way to verify the resume image when returning from hibernate. With this limitation of the Linux kernel not being able to verify the kernel image upon resume, it compromises the Secure Boot trust model. Ultimately, the Linux kernel will need to be changed so that it can work with signed hibernate images.

The kexec support needs to be disabled when running in Secure Boot since the kernel execution mechanism could be used as an attack vector by a malicious user. Using kexec could bypass the Secure Boot trust model to load a modified kernel. Ultimately, the Linux kernel will need to be improved to support signed kexec payloads.

The kexec and hibernate disabling patches can be found on the Linux kernel mailing list in a patch series entitled by Matthew as Secure Boot: More controversial changes. "These patches break functionality that people rely on without providing any functional equivalent, so I'm not suggesting that they be merged as-is. kexec allows trivial circumvention of the trust model (it's trivially equivalent to permitting module loading, for instance) and hibernation allows similar attacks (disable swap, write a pre-formed resume image to swap, reboot). The hibernation patch also shows up a different issue - some userspace drops all capabilities, resulting in things that userspace expects to work no longer working. This seems like an unsurprising result, but breaking userspace is bad and so it'd be nice to figure out if there's another way to handle this."

Matthew, now working at Nebula rather than Red Hat, also posted a set of 15 patches for Secure Boot policy support. "Secure boot makes it possible to ensure that the on-disk representation of the kernel hasn't been modified. This can be sidestepped if the in-memory representation can be trivially altered. We currently have a large number of interfaces that permit root to perform effectively arbitrary modifications to the kernel, so this patchset introduces a new capability ("CAP_COMPROMISE_KERNEL") that controls whether or not these features are available. The aim is for this to be useful in any other situations where kernel integrity can be assured by some other mechanism rather than special casing UEFI."