[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.

BIOS setup save the day!

Date: 2011-09-21 03:13 pm (UTC)
From: (Anonymous)
What about going to BIOS setup and disable Secure Boot feature and install whatever you like?
Market will decide if PC sold without this BIOS feature will be well accepted by customers...

Re: BIOS setup save the day!

Date: 2011-09-21 05:42 pm (UTC)
From: (Anonymous)
Having to disable a scary BIOS option that says "Don't disable this for security reasons." in the on-screen help, is likely to dissuade many users from trying out Linux via a LiveCD. The failed Windows 8 boot when they stop trying out the LiveCD and reboot without resetting the flag may also persuade them that Linux broke their computer.

Assuming the BIOS permits the option - as mentioned elsewhere, remove the feature, and that's one less thing you have to debug on your budget PC, one less thing you have to provide support for - there will be a whole new class of boot failures when Windows 8 users flip the option for whatever reason.

Even those of us who are tech-savvy are going to get *really* annoyed flipping the state every time they switch OS. I do as much work as possible in Linux but alas, my employer requires that I boot Windows fairly regularly, just to get a DHCP lease for my hardware. I also like to play games, and faffing about with Wine is not what I would call conducive to leisure. New games will probably start requiring secure boot anyway so you can't cheat.

The shame of it is, the feature has a legitimate use, and is probably a good thing for Windows users, who let's face it, need more security.

The only acceptable implementation would be one which permitted you to add keys to the keystore at boot time, in the BIOS setup, via entry of a checksum-verified key block. Then you don't need to buy a "blessed" proprietary OS just to add keys. Alas, this would be an even more serious deterrent to any casual use of Linux on a given piece of hardware.

So all in all, I wouldn't prohibit this feature - that would seem to be against the Free Software ethos, after all. And it's going to be good for Windows users. But I would mandate that any implementation also provides...

  • Ability to add signing keys to the keystore via BIOS setup

    • Although it's obviously better to get an OSS friendly key in there from the get-go, so the common distros can get their bootloaders signed.

  • The ability to disable secure boot with one key at boot time

    • Perhaps with the ability to choose to boot a given volume in non-secure mode, from the usual BIOS boot
      choice menu.

    Re: BIOS setup save the day!

    Date: 2011-09-21 06:50 pm (UTC)
    From: [identity profile] grvrulz.wordpress.com
    That'll defeat the purpose of this anti-feature. The key system is not being implemented for security, it is there for vendor-lock-in. I believe its time for dual booters to make a choice.

    Re: BIOS setup save the day!

    Date: 2011-09-22 04:39 pm (UTC)
    From: (Anonymous)
    The problem is mainstream PC buyers don't know anything about BIOS or Linux anyway...so computers will sell and I see the used computer market turning into a mess. You won't be able to buy a used computer and put Linux on it...

    The original buyer won't care and will buy it.

    Re: BIOS setup save the day!

    Date: 2011-10-28 08:11 pm (UTC)
    From: (Anonymous)
    "my employer requires that I boot Windows fairly regularly, just to get a DHCP lease for my hardware"

    How in the world are DHCP and IP addresses OS dependent? Why would you need Windows to get an IP address from DHCP?


    Matthew Garrett

    About Matthew

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

    Page Summary

    Expand Cut Tags

    No cut tags