The 12.10 release is the first version
of Ubuntu that supports Secure Boot out of the box. In what is largely
an accident of release timing, from what I can tell (and please correct
me if I'm wrong), this actually makes Ubuntu 12.10 the first general
release of any OS to support Secure Boot. (Windows 8 of course is also
now available; and I'm sure Matthew Garrett, who has been a welcome
collaborator throughout this process, has everything in good order for the
upcoming Fedora 18 release.)

That's certainly something of a bittersweet achievement. I'm proud of
the work we've done to ensure Ubuntu will continue to work out of the
box on the consumer hardware of the future; in spite of the predictable
accusations on the blogowebs that we've sold out, I sleep well at night
knowing that this was the pragmatic decision to make, maximizing users'
freedom to use their hardware. All the same, I worry about what the
landscape is going to look like in a few years' time. The Ubuntu
first-stage EFI bootloader is signed by Microsoft, but the key that is used
for signing is one that's recommended by Microsoft, not one that's required
by the Windows 8 certification requirements. Will all hardware include this
key in practice? The Windows 8 requirements also say that every machine
must allow the user to disable Secure Boot. Will manufacturers get this
right, and will users be able to make use of it in the event the manufacture
didn't include the Microsoft-recommended key? Only time will tell. But I
do think the Linux community is going to have to remain engaged on this for
some time to come, and possibly hold OEMs' feet to the fire for shipping
hardware that will only work with Windows 8.

But that's for the future. For now, we have a technical solution in 12.10
that solves the parts of the problem that we can solve.

The first-stage UEFI bootloader on 12.10 install media is a build of
Matthew Garrett's shim code, embedding a
Canonical UEFI CA and signed by Microsoft. This is pretty much the same
as the Fedora solution, just with a different key and a binary built on
the Ubuntu build infrastructure rather than Fedora's. If Secure Boot is
not enabled, the second-stage bootloader is booted without applying any
checks. If Secure Boot is enabled, the signature is checked on the second
stage before passing control, as expected.

The second-stage bootloader is GRUB 2. Readers may remember that there
were earlier concerns about GPLv3 in the mix for some Ubuntu use cases, but
these have been ironed out
now
in discussion with the FSF. This enables us to continue to provide a
consistent boot experience across the different ways Ubuntu may be booted.

We are providing signed kernel images in the Ubuntu archive and using them
by default. When a signed kernel is present, this allows the bootloader to
pass control to the kernel without first calling ExitBootServices(), letting
the kernel apply any EFI quirks it might need to (such as for bug #1065263.

Unlike Fedora, however, we are not enforcing kernel signature checking.
If the kernel is unsigned and the system has Secure Boot turned on, the
Ubuntu grub will fall back to calling ExitBootServices() first, and then
booting the kernel. This way, users still have the freedom to boot their
own kernels on Secure Boot-enabled hardware, possibly with a slightly
degraded boot experience, while the firmware remains protected from
untrusted code.

We are not enforcing module signing. This allows external modules, such
as dkms packages, to continue to work with SB turned on. While there's
potential value in being able to verify the source of kernel modules at load
time, that's not something implemented for this round, and we would want
such enforcement to be optional regardless.

This first release gives us preliminary support for booting on Secure Boot,
but there's more work to be done to provide a full solution that's
sustainable over the long term. We'll be discussing some of that this week
at UDS in
Copenhagen.

The 12.10 solution does not include support for SuSE's MOK (machine owner
key) approach.
Supporting this is important to us, as this helps to ensure users have
freedom and control over their machines instead of being forced to choose
between disabling Secure Boot and only running vendor-provided kernels.
Among other things, we want to make sure people have the freedom to continue
doing kernel and bootloader development, without having to muddle their way
through impossible firmware menus!

We will be enhancing the tooling around db/dbx updates, to ensure that
Ubuntu users of Secure Boot receive the same protection against malware that
Windows users do. This also addresses the need for publishing revocations
in the event of bugs in our grub or kernel implementations that would
compromise the security of Secure Boot.

Netboot support is currently nonexistent. The major blocker seems to be
that unlike in BIOS booting we can't rely on the firmware's PXE stack, and
in practice GRUB2's tftp support doesn't seem to be very robust yet. Once
we have a working GRUB2 image that successfully reads files over tftp, we
can evaluate signing it for Secure Boot as well.

And as part of our committment to enabling new hardware on the current LTS
release, we will be backporting this work for inclusion in 12.04.2.

It remains to be decided how Debian will approach the Secure Boot question.
At DebConf 12, many people seemed to consider it a foregone conclusion that
Debian would never agree to include binaries in main signed by third-party
keys. I don't think that should be a given; I think allowing third-party
signatures in main for hardware compatibility is consistent with Debian's
principles, and refusing to make Debian compatible with this hardware out of
the box does nothing to advance user freedom. I hope to see frank
discussion post-wheezy about keeping Debian relevant on consumer hardware of
the future.