UEFI secure booting

Since there are probably going to be some questions about this in the near
future:

The UEFI secure boot protocol is part of recent UEFI specification releases.
It permits one or more signing keys to be installed into a system firmware.
Once enabled, secure boot prevents executables or drivers from being loaded
unless they're signed by one of these keys. Another set of keys (Pkek)
permits communication between an OS and the firmware. An OS with a Pkek
matching that installed in the firmware may add additional keys to the
whitelist. Alternatively, it may add keys to a blacklist. Binaries signed
with a blacklisted key will not load.

There is no centralised signing authority for these UEFI keys. If a vendor
key is installed on a machine, the only way to get code signed with that key
is to get the vendor to perform the signing. A machine may have several keys
installed, but if you are unable to get any of them to sign your binary then
it won't be installable.

This impacts both software and hardware vendors. An OS vendor cannot boot
their software on a system unless it's signed with a key that's included in
the system firmware. A hardware vendor cannot run their hardware inside the
EFI environment unless their drivers are signed with a key that's included
in the system firmware. If you install a new graphics card that either has
unsigned drivers, or drivers that are signed with a key that's not in your
system firmware, you'll get no graphics support in the firmware.

Microsoft requires that machines conforming to the Windows 8 logo program
and running a client version of Windows 8 ship with secure boot enabled. The
two alternatives here are for Windows to be signed with a Microsoft key and
for the public part of that key to be included with all systems, or
alternatively for each OEM to include their own key and sign the
pre-installed versions of Windows. The second approach would make it
impossible to run boxed copies of Windows on Windows logo hardware, and also
impossible to install new versions of Windows unless your OEM provided a new
signed copy. The former seems more likely.

A system that ships with only OEM and Microsoft keys will not boot a generic
copy of Linux.

Now, obviously, we could provide signed versions of Linux. This poses
several problems. Firstly, we'd need a non-GPL bootloader. Grub 2 is
released under the GPLv3, which explicitly requires that we provide the
signing keys. Grub is under GPLv2 which lacks the explicit requirement for
keys, but it could be argued that the requirement for the scripts used to
control compilation includes that. It's a grey area, and exploiting it would
be a pretty good show of bad faith. Secondly, in the near future the design
of the kernel will mean that the kernel itself is part of the bootloader.
This means that kernels will also have to be signed. Making it impossible
for users or developers to build their own kernels is not practical.
Finally, if we self-sign, it's still necessary to get our keys included by
ever OEM.

There's no indication that Microsoft will prevent vendors from providing
firmware support for disabling this feature and running unsigned code.
However, experience indicates that many firmware vendors and OEMs are
interested in providing only the minimum of firmware functionality required
for their market. It's almost certainly the case that some systems will ship
with the option of disabling this. Equally, it's almost certainly the case
that some systems won't.

It's probably not worth panicking yet. But it is worth being concerned.