UEFI Secure Boot and Ubuntu - implementation

Canonical provided an update earlier today on our plans for implementing compatibility with UEFI's new "Secure Boot" mechanism in Ubuntu: http://blog.canonical.com/2012/06/22/an-update-on-ubuntu-and-secure-boot/ I'd like to provide a brief update on the technical details of this implementation so that people have some idea of what's happening. Boot loader selection ===================== UEFI Secure Boot allows users to install their own keys and sign boot loaders themselves, and in that case the boot loader can do whatever the user is comfortable with. However, Ubuntu needs to boot out of the box on factory systems if at all possible, and that means playing by the rules of whoever owns the keys installed on those systems. Typically, that means that the boot loader must not execute any unsigned code in a firmware context, that is, before ExitBootServices is called just before jumping into the kernel. So, the bad news first: at this point, we are not planning to use GRUB 2 by default on systems with secure boot enabled. As a search through its ChangeLog will show, we've put a considerable amount of upstream development effort into GRUB 2 and we hope to carry on doing so, so this wasn't an easy decision. Matthew Garrett has outlined Fedora's plans in some detail elsewhere, and they do involve GRUB 2. The reason we've arrived at a different plan is that Ubuntu has a rather extensive base of preinstalled systems. Microsoft's Windows 8 logo requirements do say that there must be a way for users to disable secure boot or to install their own keys, and we strongly support this in our own firmware guidelines; but in the event that a manufacturer makes a mistake and delivers a locked-down system with a GRUB 2 image signed by the Ubuntu key, we have not been able to find legal guidance that we wouldn't then be required by the terms of the GPLv3 to disclose our private key in order that users can install a modified boot loader. At that point our certificates would of course be revoked and everyone would end up worse off. (Plus, Fedora is going to have to lock down GRUB 2 a certain amount itself to make sure that it can't execute unsigned code before ExitBootServices, which seems likely to come at some cost to its flexibility.) So, at this point, despite the fact that we clearly don't want to be part of delivering locked-down PCs to users, it looks as though we need to use a boot loader with a more liberal licence in order to protect ourselves from accidents. GRUB Legacy with Red Hat's EFI patch stack would probably do, but we really don't have much interest in resurrecting that code if there's any possible alternative at all. The kernel has an EFI boot stub nowadays, but we'd like a bit more pre-boot flexibility: at least a menu. Our current plan is to use Intel's efilinux loader with some modifications to add a relatively simple menu interface. Kernel signing ============== We believe that the intention of secure boot is to protect against malicious use or modification of pre-boot code, before the ExitBootServices UEFI service is invoked. Currently, this call is performed by the boot loader, before the kernel is executed. Therefore, we will only be requiring authentication of boot loader binaries. Ubuntu will not require signed kernel images or kernel modules. Key management ============== As announced earlier today, we've generated an Ubuntu signing key for use with UEFI. The private half of this key will be stored securely on our Launchpad infrastructure, which will be responsible for signing boot loader images and distributing them in the Ubuntu archive. Booting our CDs will rely on a loader image signed by Microsoft's WinQual key, for much the same reasons as Fedora: it's a key that, realistically, more or less every off-the-shelf system is going to have, as it also signs things like option ROMs, and the UEFI specification only allows an image to be signed by a single key. This will then chain to efilinux signed by our own key (so we don't have to go through the WinQual signing process every time we want to make a minor change there). We hope that we'll also be able to make the first stage loader detect whether Secure Boot is enabled and otherwise chain to GRUB 2, to ensure that we don't regress behaviour for those with UEFI systems that do not implement Secure Boot or that have it disabled. Ubuntu preinstalled machines ============================ For machines where Canonical has been engaged to preinstall Ubuntu, the situation does not differ significantly from the configuration a user would find if they bought a machine off the shelf and then installed Ubuntu. The only functional difference from such a post-sale Ubuntu install will be the addition of an Ubuntu key in firmware. Machines that ship as "Ubuntu certified" will be required to have an Ubuntu key configured in their UEFI signature databases. The intention here is to allow these systems to receive updates for the revoked signature database, in order to be protected against known-compromised UEFI binaries. We are not planning to provide an alternative to Microsoft's signing infrastructure, only an additional key; so we have no current plans to implement a signing service using the Ubuntu key. When implemented, this functionality will not be restricted to preinstalled Ubuntu systems. Provided that their UEFI firmware allows key reconfiguration, all users will be able to add the Ubuntu key manually, and receive the same updates. We will be requiring that the standard Microsoft key be present in the Ubuntu certification process. This means that an Ubuntu certified machine will be no more locked down than other machines on the market, and will be compatible with any UEFI binaries that can be used on a Windows machine. -- Steve Langasek, Colin Watson, and Jeremy Kerr