[personal profile] mjg59
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.

Re: Kernel itself is part of the bootloader?

Date: 2011-09-21 07:38 am (UTC)
From: (Anonymous)
https://lwn.net/Articles/458789/ has some ideas around that, specifically:

Harald had a proposal for improving the situation: rather than add complexity to boot loaders in an attempt to keep up with the kernel, why not just boot a simple generic Linux kernel and let it deal with the rest? His idea is to create a /firstboot directory with a simple filesystem and populate it with a single Linux kernel and an initramfs image whose sole purpose is to find the real kernel and boot that. This kernel will naturally understand Linux filesystems, and it will support a user space with enough power to run whatever scripts are needed to find other bootable images on the system. Meanwhile, the initial boot loader can be made to be as simple as possible and distributions can stop messing with the MBR.

Re: Kernel itself is part of the bootloader?

Date: 2011-09-21 08:21 am (UTC)
From: (Anonymous)
it is already possible to boot linux without messing with the MBR.
the extlinux bootloader supports being installed into the header or a regular partition (like the linux /boot or root partition) and boot linux from there.

the foresight linux distribution uses extlinux in such a way by default.

greetings, eMBee.

Re: Kernel itself is part of the bootloader?

Date: 2011-09-21 01:08 pm (UTC)
From: (Anonymous)
And LILO as well (heck you could even install the loader info for the Linux distribution you just installed onto the hard drive onto a floppy disk!). Just go way back in the slackware or redhat trees to see

Re: Kernel itself is part of the bootloader?

Date: 2011-09-21 09:50 am (UTC)
From: (Anonymous)
You can't be sure to have a working system if you are booting one Linux version with another Linux version:
Moreover, if you want to boot a CD-ROM/DVD (El-Torito, i.e. all of them) you can't use EFI or Linux; you can't cleanly return to BIOS after switching to protected mode.
I wonder if EFI is not made to stop user booting from DVD, the only time you need that is to install Linux anyway... Windows is always pre-installed (and when Windows died due to a virus, it is time to buy a new PC).

Re: Kernel itself is part of the bootloader?

Date: 2011-09-21 03:19 pm (UTC)
From: [identity profile] http://users.livejournal.com/deviant_/
No, booting DVDs works just fine in UEFI, which (except on Apple machines) uses El Torito just like you'd expect.

Re: Kernel itself is part of the bootloader?

Date: 2011-09-21 03:41 pm (UTC)
From: (Anonymous)
Well, you can start DVD before starting the EFI layers, but once the CPU is in protected mode (for EFI) you will have problems to execute your real-mode El-Torito code, with BIOS disk call back to read the end of the loader from the DVD.
There probably could be an extended El-Torito which has EFI protected mode code, but that will not be the standard DVD.


Matthew Garrett

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at Google. Ex-biologist. @mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer.

Expand Cut Tags

No cut tags