UEFI Secure Boot and Ubuntu - implementation

[Steve Langasek]

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