Preparing the kernel for UEFI secure boot

The problem, simply put, is this: the objective of secure boot is to prevent the system from running any unsigned code in a privileged mode. So, if one boots a Linux system that, in turn, gives access to the machine to untrusted code, the entire purpose has been defeated. The consequences could hurt both locally (bad code could take control of the machine) and globally (the signing key used to boot Linux could be revoked), so it is an outcome that is worth avoiding. Doing so, however, requires placing limitations in the kernel so that not even root can circumvent the secure boot chain of trust.

The form of those limitations can now be seen in Matthew Garrett's secure boot support patch set. These patches may see some changes before finding their way into the mainline, but chances are that their overall form will not evolve that much.

The first step is to add a new capability bit. Capabilities describe privileged operations that a given process can perform; they vary from CAP_DAC_OVERRIDE (able to override file permissions) to CAP_NET_BIND_SERVICE (can bind to a low-numbered TCP port) to CAP_SYS_ADMIN (can do a vast number of highly privileged things). The new capability, called CAP_SECURE_FIRMWARE, enables actions that are not allowed in the secure boot environment. Or, more to the point, its absence blocks actions that might otherwise enable the running of untrusted code.

Naturally, the first thing reviewers complained about was the name. It describes actions that can be performed in the absence of "secure firmware"; some reviewers have also disputed whether it has anything to do with security in the first place. So the capability will probably be renamed, though nobody has come up with an obvious replacement yet.

Whatever it is eventually called, this capability will normally be available to privileged processes. If the kernel determines (by asking the firmware) that it has been booted in the secure mode, though, this capability will be removed from the bounding set before init is run; once a capability is removed from that set, no process can ever obtain it. Matthew's patch set also adds a boot-time parameter (secureboot_enable=) that can be used to simulate a secure boot on hardware that lacks that feature.

In the secure boot world, processes lacking the new capability can no longer access I/O memory or x86 I/O ports. Either of those could be used convince a device to overwrite the running kernel with hostile code using DMA, compromising the system, so they cannot be allowed. One consequence is that graphics cards without kernel mode setting (KMS) support cannot be used; fortunately, the number of systems with (1) UEFI firmware and (2) non-KMS graphics is probably countable using an eight-bit signed value. Other user-space device drivers will be left out in the cold as well. Someday, Matthew says, it may be possible to enable I/O access on systems where the I/O memory management unit can enforce restrictions on the range of DMA operations, but, for now, all such access is denied.

Similarly, all write access to /dev/mem and /dev/kmem must be disabled, even if the kernel configuration would otherwise allow such access.

The strongest comments came in response to another limitation — the disabling of the kexec() system call. This call replaces the running kernel with a new kernel and boots the result without going through the system's firmware. It can be used for extra-fast reboots, though the most common use, arguably, is to boot a special kernel to create a crash dump after a system failure. Booting an arbitrary kernel obviously goes against the spirit of secure boot, so it cannot be allowed.

Eric Biederman, in particular, complained about this limitation, saying:

Matthew responded that, in fact, we can't always trust root, and never have trusted it fully:

In this case, the proper solution would appear to be to allow kexec() to succeed if the target kernel has been properly signed. That support has not yet been implemented, though. It's apparently on the to-do list, but, as Matthew said: "We ship with the code we have, not the code we want."

One other important piece of the puzzle, of course, is module loading; if unsigned modules can be loaded into the kernel, the game is over. But, unlike kexec(), module loading cannot simply be turned off, so the implementation of some sort of signing mechanism cannot be put off. The module signing implementation is not part of Matthew's patch set, though; instead, David Howells has been working on the problem for some time now. This code has been delayed as the result of strong disagreements on how signing should be implemented; a solution was worked out at the 2012 Kernel Summit and this feature, in the form of a new patch set from Rusty Russell, should find its way into the mainline as soon as the 3.7 development cycle.

The end result is that, by the time users have machines with UEFI secure boot capabilities, the kernel should be able to do its part. Whether users will like the result is another story. There is great value in knowing that the system is running the software you want it to be running, and many users will appreciate that. But others may find that the system is refusing to run the software they want; that is harder to appreciate. If things go well, the restrictions required by UEFI secure boot will come to be seen like other capability-based restrictions in Linux: occasionally obnoxious, but good for the long-term stability of the system and ultimately circumventable if need be.