Some things that strike me about Linux and UEFI secure booting

June 1, 2012

When I read Matthew Garrett's Implementing UEFI Secure Boot in Fedora, a number of things struck me about the situation (for his background on UEFI secure boot, see part 1, part 2, more, and especially this). The basic setup is that Microsoft is requiring that any hardware that wants to carry a 'Windows 8 ready' logo must support UEFI secure boot and must have it turned on.

(Actually, when I read Garrett carefully the last bit is not clear. He says that if Windows 8 is preinstalled UEFI secure boot must be enabled, but he doesn't say that a motherboard merely marked with the Windows 8 logo program must have secure boot turned on. It's possible that this is not a Microsoft requirement and that motherboard and system vendors may thus ship bare machines with UEFI secure boot turned off. We probably won't know until Windows 8 logo hardware starts shipping.)

First, something that's worth noting explicitly:

UEFI secure boot enabled machines will not boot unsigned CDs or USB sticks without you manually changing the BIOS settings.

This hits both install media and 'live CDs' (these days as likely to be a USB stick as a physical CD or DVD), and also PXE netbooting. Signed media can boot automatically, but not unsigned media. Among other things, this is a real usability hit for unsigned installers; you can't even boot the installer to an instruction screen about the need to disable secure boot in the BIOS. And as Garrett notes in his series, Microsoft has not mandated a specific UI for disabling secure boot in the BIOS so everyone is going to do it differently.


  • Ubuntu (well, Canonical) is going to do what Fedora is; they just aren't talking about it publicly (yet).

    Any mass-market focused Linux distribution faces exactly the same problem as Fedora does here. Usability requires that you not need people to fiddle with their BIOS, and that means you need to be signed. Ubuntu is if anything more focused on easy desktop usability than Fedora is, so they are going to have to get signed somehow. Outside Ubuntu contributors may not like this very much when it happens, but Canonical is going to force it through.

    I expect other mass-market focused distributions to blink as well, although SUSE is the only one I can think of offhand.

    (The flipside is that I will be very surprised if Debian goes with signing; it would be very hard to square it with their principles, and Debian really cares about those principles.)

  • As Garrett covered here, this means that the proprietary binary Nvidia and ATI graphic drivers are dead for mass-market Fedora users (the ones who do not go into their BIOS and disable UEFI secure boot), including Nvidia's CUDA environment. Fedora is extremely unlikely to sign binary drivers for Nvidia and ATI, and you cannot give users the ability to load them anyways. This is not just a Fedora issue, of course; any mass-market focused distribution has the same problem (assuming that they get signed for usability reasons, per above), including and especially Ubuntu.

    This is going to be very unpopular, to put it mildly. My strong impression is that a lot of people use the proprietary drivers, especially with Nvidia hardware.

    (It's possible that Canonical will figure out some way that they can sign the drivers; of all of the Linux distributions, I think they will be the most willing to hold their noses and compromise. I don't think that this will work in the long run, partly because I expect the binary drivers to be a fruitful source of exploitable kernel bugs once people have a motive to start looking.)

  • Hardware compatibility lists are coming back, although not right away.

    Based on Garrett's writeups of general BIOS issues, I have the strong impression that one of the golden rules of PC BIOSes is that if Windows doesn't need something for booting and Microsoft doesn't explicitly test it in their hardware certification tests, it doesn't work. While Microsoft requires that BIOS vendors support turning secure boot off, we don't know how well they're going to actually test this (and it seems unwise to assume that they'll do it thoroughly).

    In the short term there will probably be enough pressure from people wanting to run old versions of Windows to keep the BIOS vendors honest. But in a few years, well, I'm not that optimistic. Laptops will probably be the canary in the coal mine here, since my impression is that most laptops aren't reinstalled with older versions of Windows and so most laptop buyers wouldn't notice if UEFI secure boot couldn't be turned off.

  • I have no clue how this is going to interact with Linux and Fedora support for virtualization. If Fedora leaves virtualization alone, the problem is that at least in theory you could construct a properly signed Fedora install that immediately booted Windows in a full screen virtualized environment with a compromised 'UEFI secure boot' BIOS and boot time malware.

    (I'm using Fedora here as an example; you could do the same thing with any Linux distribution that gets itself signed and supports virtualization.)

    Everything that I can think of to do to block this (or make it obvious that it's happening because Windows 8 runs really slowly or without the graphics bling that it should have) makes virtualization less useful or extends signing further and further into user-level components, or both. A good virtualization environment does want to offer fast graphics, good access to USB hardware, direct use of disk partitions, and so on. And all of these are highly useful for creating this sort of fake Windows virtual environment.

In the short term I'm more optimistic than Garrett is about how easy it will be to turn UEFI secure boot off. Since (as far as I know) older versions of Windows will not boot on UEFI secure boot machines, as long as a significant number of people will want to install them the BIOS vendors have a strong motivation to make this as easy as possible. The absolutely easiest way would be a boot-time popup that says 'you are trying to boot an unsigned thing; continue anyways?'

(This may wind up be disallowed by Microsoft's Windows 8 requirements, of course. Just like all other security warnings, the easier it is for users to disable secure boot the less effective it is at preventing boot time malware because almost all users will just reflexively override the warning if they can. BIOS vendors don't care about this, but Microsoft does and they may put their foot down.)

Written on 01 June 2012.
« The secure boot problem
My view on Mercurial versus Git »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Jun 1 15:35:07 2012
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.