Supporting UEFI secure boot in Debian

Hutchings started by reviewing how the secure boot technology works. On systems with secure boot, the UEFI firmware is able to validate the system's bootloader by checking its signature against a list of trusted keys; it can also validate UEFI drivers and firmware updates. This checking is intended to defend the system against persistent malware by ensuring that the system's low-level software has not been tampered with. Support for secure boot is mandatory for systems that will run Windows, so all desktop systems sold since 2012 have it. It is possible to build in trust for multiple signing keys but, in practice, the one key that is trusted by everybody is Microsoft's key.

To boot Linux on a system with secure boot enabled, the first stage bootloader must have a Microsoft signature; in the Linux world, that is usually the special "shim" utility. Distributors create their own signing key, which they then build into shim; that key is then used to verify the GRUB installation. GRUB, in turn, verifies the signature for the kernel image; the kernel must validate any modules that it loads. By checking for proper signatures at every stage of the boot process, the system can be protected against hostile software modifications.

Supporting secure boot requires some fundamental changes in how Linux systems work. Traditionally, the root account can run arbitrary code, but that cannot be allowed under secure boot; even root should be unable to fully take over the system. To keep that from happening, the module loader must check signatures on kernel modules. The "kexec" mechanism must be prevented from booting into an arbitrary, unsigned image. Various I/O devices that are capable of modifying arbitrary memory must be disabled. The hibernation mechanism must be disabled entirely, though future work could, by signing and verifying the hibernation image, make that work again. Debian will be using Matthew Garrett's patches that make these changes; the patches are still not upstream and may never be, though, since certain high-profile kernel developers dislike them.

The Debian way

The commonly-used approach of signing the kernel image creates some problems for Debian, though. The project's practice with signatures has been to sign metadata describing software, never the code itself. Debian does not want to put signing keys onto its "buildd" systems; those systems are distributed around the globe and present any number of ways in which the keys could be exposed. Debian is also committed to reproducible builds, which cannot depend on secrets (or they would no longer be reproducible).

As a result, Debian cannot automatically build signed kernel binaries in a single step. Instead, the process starts with the creation of an unsigned binary. The signature for that binary is then created offline and a second source package is created to contain it. A second-stage build then rebuilds the kernel binary and applies the signature to it, resulting in a new package with a fully signed kernel binary. As long as the build is truly reproducible, the signature will still apply to the recreated binary. This mechanism allows anybody to create a signed Debian kernel image — as long as it precisely matches the kernel that was created by Debian itself.

Some changes to the Debian Archive Kit (dak) software, which signs archive metadata, will be needed, since it now needs to be able to publish detached signatures too. It may be necessary to publish the signature without publishing the accompanying binary immediately; this could happen in response to an embargoed security issue, for example. There is a script that turns a tarball of EFI binaries (and kernel modules) into a tarball of signatures, which are then installed into the archive metadata. The source package for the initial build is changed to include this tarball, along with a preparation script used by the second-stage build.

Some might wonder whether Ubuntu had already done this sort of work. Ubuntu's solution doesn't work for Debian, though, for a number of reasons, starting with the fact that Ubuntu's package builder doesn't use dak. Ubuntu's signing script only covers EFI binaries, leaving modules unsigned; it also creates signed binaries directly instead of using the two-stage signing process that Debian requires. Ubuntu only supports the amd64 architecture; Debian wants to support all architectures where secure boot is relevant. One other little complication is that the Ubuntu and Debian kernel packages have diverged significantly over the last ten years. The two projects do share some of the utilities, though, including shim and the grub-signed bootloader.

What about the ARM architecture? The upstream kernel has EFI stub support for both 32-bit and 64-bit ARM systems. Debian has out-of-tree securelevel patches that work for arm64; other tools, including sbsigntool, shim, and the GRUB EFI code, also work there. So it should be possible to support arm64 systems under secure boot, at least. The smaller ARM systems that feature secure boot are locked down and will only run Microsoft software, but that should be less of a problem in the server space.

Julien Cristau stepped up briefly to talk about how signing keys will be managed as this whole thing goes into production. Once again, the Ubuntu example is only so helpful for Debian. Ubuntu has its own data center, under its control, with the result that it has relatively good security for its machines. Debian lacks this data center, depending instead on machines hosted in various places around the world; it can thus never have as good a handle on the security of those machines. Signing keys will need to be kept in a hardware token, such as a YubiKey device. Patches are in the works to make all of this work in a secure manner.

Where things stand

Hutchings came back to summarize the status of this work; the current state of affairs can also be found in the Debian bug tracker as bug #820036. The changes to dak are in progress, and can be expected soon. The shim package is done, and is in review; there is still a need to put together a signed GRUB build. The signed build for the kernel is ready to go, but a signed build for the fwupdate utility is not ready yet. The installer and live images are ready to work with signed binaries, as is the support to actually install it all. The target for this work is the Debian 9 ("Stretch") release, which goes into freeze in January. More information can be found on the Debian secure boot wiki page.

The first question from the audience had to do with the UEFI signing key: would it be possible to use a separate key and avoid the need for Microsoft's signature? There is some appeal to that approach, but it has a big disadvantage: users would would have to install the new key in their firmware. There are a lot of different firmware implementations out there, each of which has its own horrible interface for key installation. Creating documentation to get Debian users through that process would not be fun.

Why is Debian only coming out with secure boot support now? Hutchings responded that the project has wanted this support all along, but has obviously been slow in implementing it. There has been a lot of talk about how to do it, but nobody actually got the work done. As a result, it's still not possible to install Debian without disabling secure boot in the firmware. That is about to change, though, now that support for secure boot is almost ready.

The final question suggested that, if Debian were to continue to not support secure boot, that might force vendors to make the feature easier to do without. Hutchings's response there was a dry "it's still not the year of the Linux desktop"; he does not believe that Linux distributors can push desktop hardware vendors around in that way.

[Your editor thanks Kernel Recipes for supporting his travel to this event.]