Ubuntu details its UEFI secure boot plans

UEFI Secure boot is expected to interfere with many users' desire to replace Windows or dual-boot it with Linux, because Microsoft is mandating that secure boot be enabled on Windows 8 machines at the time of sale. On June 5, we reported on Fedora's plans for handling the secure boot mechanism in UEFI. Ubuntu has subsequently announced its own plans, which take a different approach.

To recap, the secure boot feature constrains the hardware only to boot software that has been signed by a known cryptographic key. The point is that booting only signed, trusted binaries prevents attacks through boot-time malware that could be undetectable after the infected system is up and running. Microsoft is requiring hardware vendors to have secure boot enabled if they want to include the official logo for the upcoming Windows 8, although x86 vendors are also required to allow the machine's owner to turn off secure boot entirely or to install new keys. That option is regarded as insufficient for several reasons, notably that there may be users who are required (e.g., by office rules) to keep secure boot switched on, and that entering new keys for every alternative OS is likely to be an arduous process (even more so for the scenario where one needs to boot a temporary OS, such as from a CD or USB key).

Fedora's strategy is to enroll in Microsoft's developer program, which allows the project to purchase an approved $99 key through Verisign, a key which will be recognized by UEFI secure boot. The key will be used to sign the shim bootloader, which is a "trivial UEFI first-stage bootloader" whose only job is to boot GRUB2. Fedora will also sign the GRUB2 bootloader and the kernel, although the latter two binaries can be signed with the Fedora project's own keys.

Ubuntu's plan

Canonical posted a brief announcement about its own secure boot plan on the company blog on June 22, although the details were to be found in Steve Langasek's message to the ubuntu-devel mailing list. Canonical has generated its own signing key which will be pre-loaded on machines that ship with Ubuntu already installed. Ubuntu CDs will ship with a shim bootloader (the same shim bootloader used by Fedora) signed by one of the existing Microsoft-certified keys, much like the Fedora plan.

After that point, however, the distribution is taking a markedly different approach to the trusted bootloader chain. An Ubuntu system will boot into the efilinux bootloader, which will in turn boot an unsigned kernel image. Under Fedora's plan, the shim bootloader verifies the integrity of GRUB2 before loading it, and GRUB2 in turn verifies the integrity of the kernel. Canonical says that their reading of the specification makes it clear that their secure boot responsibilities stop at the bootloader, and do not extend to the kernel:

The decision to use efilinux has its own justification. Because GRUB2 is licensed under the GPLv3, Canonical determined that machines with Ubuntu pre-installed are subject to the "User Product" provisions of GPLv3, which requires that the distributor provide the user with all authorization keys required to install the software. The company consulted with the FSF about that topic, and were warned that the authorization key clause would probably (although not definitely...) apply. Thus, if a hardware vendor shipped an Ubuntu system and did not include a way for users to install keys of their own, Canonical would be compelled to disclose its key. Revealing the signing key would undermine the point of secure boot and "at that point our certificates would of course be revoked and everyone would end up worse off."

Signatures, revocation, and other fine print

Ubuntu's decision to use its own key for pre-installed machines has spawned relatively little debate, but there is a sharp disagreement over the decision not to sign kernel images. Red Hat's Matthew Garrett (who authored the Fedora secure boot plan) argued that signing only the bootloader is insufficient:

Jamie Strandboge replied that "the UEFI specification and the Windows 8 logo requirements is that Secure Boot is designed to protect early boot only," and that signing the kernel and large portions of userspace is unattractive for several reasons, "not least of which is that it reduces the utility of the distribution."

Strandboge also contended that signing the kernel does not offer a significant level of protection over signing the bootloader, because the existence of any exploitable bootloader undermines the trust chain for all OS vendors. The argument goes that if DistroX's signed bootloader is vulnerable, malware authors could use it to create a malicious live CD image that will boot even on a machine that normally runs DistroY's secure bootloader with its signed kernel. Thus, signing the kernel image is useful for creating a trusted environment for user space, but it does not strengthen the protection of secure boot itself.

There is also the open question of how key-revocations and other updates to the secure boot world will work in practice. Both Fedora and Ubuntu plan to make use of a "shim" bootloader so that they can issue updates to the main bootloader without getting the updates signed by Microsoft. But the distributions will also need to issue revocations for vulnerable, signed bootloader and/or kernel images, and the process by which the OS vendor pushes those updates out has yet to be determined.

Although most multi-boot discussions revolve around dual-booting Windows and a single Linux distribution, that is hardly the only scenario. Canonical said that it will not offer its own signing key to sign the bootloaders of other distributions or vendors, which some feared would make it impossible to install, for example, Fedora on a machine that comes with Ubuntu pre-installed. However, the owners of machines pre-loaded with Ubuntu will still be able to install Fedora or other OSes in tandem, because the company will require its OEMs to include the Microsoft key in the secure boot key database alongside the Ubuntu key.

As Windows 8 draws near, the questions about UEFI secure boot and its impact on users continue to swirl. Clearly there are risks in handing the ultimate say in booting one's machine to a third party (particularly a rival OS vendor like Microsoft), and even though two of the largest distributions have crafted a plan for dealing with secure boot's restrictions, how much of an imposition the final product is still hinges on unknowns like the revocation and update process. But the biggest question that remains is whether it is wise to tacitly endorse secure boot by playing its games in first place. On that, the community may never arrive at a single answer.