Another approach to UEFI secure boot

On October 26, Microsoft will release Windows 8. Normally, a release of that kind would be largely uninteresting to Linux users, but Windows 8 branding brings with it a hardware requirement that will definitely impact those wanting to use Linux: UEFI secure boot. Distributions such as Fedora, SUSE, and Ubuntu have been working on their plans for supporting secure boot for more than a year now, so it may be something of a surprise that the Linux Foundation (LF) recently announced its own entrant into the secure boot derby. But the LF "pre-bootloader" is mostly meant as a stop-gap measure for those distributions that have yet to decide on their secure boot strategy.

Secure boot is meant to protect operating systems from pre-boot malware by cryptographically protecting the first step of the boot process. Only binaries signed by keys stored in the UEFI firmware will be allowed to run when secure boot is enabled—which must be the default for certified hardware. On Windows and other systems, the first-stage bootloader will check the signatures of the next steps, but that is not strictly required. Since the keys stored in the firmware are under the control of the hardware makers, it is likely that there will only be keys from Microsoft and the manufacturer stored there. That leads to the distasteful, but unavoidable, need to get bootloaders signed by Microsoft in order to boot on secure-boot-enabled systems.

Much of the hue and cry surrounding secure boot has been about the need for Microsoft-signed bootloaders, but there is little alternative. One could imagine some kind of "Linux certificate authority" that could get its key installed on systems, but that ship has sailed at this point—hardware will be available soon with just the keys from Microsoft and the vendor. Any solution for booting Linux on those systems requires a bootloader signed by Microsoft or disabling secure boot altogether. The solutions vary on exactly what that bootloader actually does.

The "pre-bootloader"

The LF approach is the "smallest piece of code we could think of" that would allow Linux to boot on Windows 8 systems, James Bottomley, member of the LF Technical Advisory Board (TAB), said in email. Bottomley did much of the work on what he calls the "pre-bootloader" that will boot any Linux—signed or unsigned—using a "present user" test. That test ensures that there is a user present at boot time. The pre-bootloader is, of course, signed by Microsoft, but instead of requiring a signature on the next stage of the boot process (typically a full-blown bootloader like GRUB2), it will load and run any code if the user at the keyboard allows it.

Beyond that, if the system is in "setup mode", the pre-bootloader will ask the user if they want the signature of the second-stage bootloader installed into the UEFI secure database. That will allow unattended booting of the system in the future. While it is mandatory under the certification requirements for hardware vendors to provide a way to put systems into setup mode (or to disable secure boot), the user interface to do so is left unspecified. That means there will be several—possibly many—different ways to put systems into setup mode. In order to collect information about these different mechanisms, the pre-bootloader will refer users to an LF web site that will be gathering and disseminating instructions for putting systems into setup mode.

The intent, Bottomley said, is "to ensure that smaller distributions [have] a policy free option they could turn to as an interim solution while they sorted our what their own security policy around secure boot would be". The pre-bootloader binary, once signed by Microsoft, will be available on the LF web site for anyone to use. Distributions that don't want to have their own bootloader signed or, indeed, participate in secure boot at all, will be able to use the pre-bootloader for both live distributions (on CD/DVD or USB devices) and for installations to the hard disk. However, users will either need to get their systems into setup mode and install the second-stage bootloader signature/hash—or be present on every boot.

Requiring users to find and enable setup mode has a minor side benefit, Bottomley said. The information on how to do that will be useful for others, to either permanently disable secure boot or to install their own keys (either in addition to the existing keys or supplanting them). For booting a live distribution, though, testing for user presence should not be that much of a burden.

Shim

There is an alternative to requiring systems to be put into setup mode or for users to be at the keyboard when booting: a pre-bootloader being used by (at least) Fedora and SUSE, called "shim". Shim takes a different approach, but still allows distributions to set their own policies. There are two main differences between it and the LF pre-bootloader, though. Shim can contain an internal keyring for keys used to sign the second-stage bootloader (or just the cryptographic hash(es) of authorized bootloaders), which will be checked in addition to the factory-installed keys. In addition, in its present incarnation, shim will not provide a way to circumvent signature/hash checking with a present user test. According to shim developer Matthew Garrett, there is strong consideration of adding that kind of test for removable media in support of live distributions and installation media, though.

Even a shim that has an internal keyring can support booting binaries that are signed by keys that don't appear on that keyring (and are not present in the firmware). It does that by using an idea that SUSE came up with for storing keys and hashes without requiring users to find and enable setup mode: the "Machine Owner Key" (MOK). It turns out that the UEFI specification provides some secure storage locations that can only be accessed (and, importantly, changed) during the boot process. Shim uses that storage as a place to put keys or hashes if the user directs it to, which avoids requiring user presence on subsequent boots.

Both Fedora and SUSE will be releasing shim binaries that contain their distribution keys on the internal keyring and are signed by Microsoft. Because of the MOK storage idea, though, those binaries could be used by other distributions. Even distributions that are not planning to sign their second stage (and their kernel) could use one of the signed shims. A recently added shim feature will add hashes (rather than just signatures) to the MOK. So a distribution that wants to minimize its dealings with secure boot can simply ship one of those shims and instruct its users to store the second-stage hash in the MOK as prompted by shim. Or those distributions can use the LF pre-bootloader.

Pre-bootloader vs. shim

That last part is a bit of a sticking point, at least for Garrett. Because the pre-bootloader comes with an LF "stamp of approval", it may well be seen as "the Linux solution" for secure boot. But Garrett believes that the pre-bootloader isn't "terribly useful". All of the functionality that it provides is also available in shim, he said, except for the ability to "hit y and it'll run whatever you want". Instead, shim users can just use the interface to add keys or hashes to the MOK and boot unattended forevermore.

There are also some dangers in the LF approach, Garrett said. Because non-technical users are easily fooled into clicking through security warnings, the pre-bootloader could be used to attack Windows:

While trojaned Windows binaries aren't directly a problem for Linux, they could be a problem for signed first-stage bootloaders. Secure boot has a database of blacklisted keys and hashes that can be used to stop malware from running on the system. If the LF pre-bootloader is used by some form of malware, it could be blacklisted. That's also true of any shim similarly used, but shim's present user "test" is a bit more complicated than that of the pre-bootloader, so malware authors may be more inclined to target the simpler test.

In any case, signed Linux first-stage bootloaders are clearly at some level of risk of being blacklisted down the road. That risk is inherent in the fact that the secure boot requirements are set by Microsoft to further its own ends. One would guess it won't use its power over the contents of the blacklist indiscriminately, but there is no technical obstacle to it doing so.

An alternative that the LF could have taken would be to create a shim with an empty keyring and get that signed, shim developer Peter Jones said in email. A shim built that way would only run code signed by the keys in the firmware. Since a shim built that way wouldn't have the key or hash for the second-stage bootloader available in the databases it consults, it wouldn't run the second stage, but it would prompt users to add that key or hash to the MOK on first boot. That would allow smaller distributions or those uninterested in signing their binaries to use shim—and avoid the present user test (or setup mode) except for the first boot.

Garrett in particular seems irritated by the LF approach. Because of the uncertainty on how to get systems into setup mode, he believes the pre-bootloader risks making Linux a second-class citizen. In the comment linked above, he warned:

Furthermore, he is unhappy that the LF went its own way, rather than working with Fedora and SUSE on shim. In another comment, Garrett is not particularly pleased with the decision to build a separate pre-bootloader after the TAB had been urged to work together on shim:

That's not quite the way Bottomley sees things, however. The LF and TAB were "exclusively concentrating on tools that keep linux booting and installing", with an emphasis on the simplest solution. As he noted, "Shim was originally designed as a solution to take advantage of secure boot and enforce a security policy rather than one that simply permits any linux distribution to boot". As a neutral party, at least with respect to distributions, the LF did not want to take sides on what kinds of secure boot policies distributions should choose:

It may well turn out that the LF pre-bootloader is simply a temporary measure and that shim can handle all of the different use cases—the LF code uses some parts of shim, after all. Or perhaps the simplicity of the pre-bootloader code will be attractive to some distributions. The pre-bootloader requirement to get the system into setup mode might be attractive to some users or distributions that want to ensure their keys are the only ones present in the system, for example. Bottomley and the LF would be fine with any of the possible outcomes:

Booting Linux on new x86 hardware is clearly going to be a bit more difficult than it has been in the past. Due to a lot of hard work from various folks, though, it will be a lot easier than it could have been. In the end, there is room for both solutions, though there is merit to Garrett's concern that the LF solution will be taken as "the Linux solution" for secure boot. At last report, Ubuntu planned to use its own first-stage bootloader, and other options may arise, so the "one true Linux secure boot solution" may never really exist.