Wandering Thoughts archives

Some things that strike me about Linux and UEFI secure booting

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.

So:

• 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.)

The secure boot problem

In theory, UEFI secure booting has the straightforward goal of stopping boot time malware, malware that compromises your machine before Windows boots and thus before any of its protections can kick in (such malware already exists, although it's not very common). In practice, secure boot requires that all privileged code your machine ever runs be signed. Your bootloader must be signed, your operating system (Windows or otherwise) must be signed, your hardware drivers must be signed. Wait, what? How did 'prevent boot time malware' turn into 'only run signed code'?

The core problem with all secure boot schemes and with this general goal of blocking boot time malware is that the OS has no way to be sure that it was booted securely. There is no way for Windows (or any other OS) to reliably detect that it was booted in a compromised environment or by something other than the official boot system and throw up a big warning when it starts to the effect that you're in trouble. If an attacker has control of the machine, they can construct a fake boot environment that lies to the target OS and says 'honest, you were booted securely, everything is fine, I am not boot time malware'. At that point it is game over.

(I'm not convinced that you can get around this in practice even with hardware support.)

This means that secure boot can never allow the attacker to gain control of the machine through any path, even a long one. A bootloader allows control of the machine, so you can only run approved, presumed secure bootloaders. An operating system allows control of the machine, so bootloaders can only run approved operating systems. Kernel level drivers allow control of the machine (if you abuse them), so operating systems can only allow approved drivers. Direct hardware access to some hardware allows you to take control of the machine (for example by programming DMA to overwrite bits of the OS), so operating systems can only allow that access to approved programs. And so on. Thus we wind up with secure boot requiring that all privileged code be signed, all the way down the line from the bootloader to graphics drivers.

Any opening in this chain of trust allows an attacker to slip in, intercept the process, take over the machine, and boot the target OS in a malware infected environment. If they can slip in early enough, you're unlikely to notice that your machine takes a few seconds longer to boot than before because it is actually booting a carefully configured minimal OS install for something that is willing to run an unsigned driver and the 'driver' is then taking the machine over to start your real OS.

Of course, the corollary of this is that signing things is not really good enough to keep attackers out. It would only be good enough if the signed things had no vulnerabilities that attackers could exploit, but of course they are going to have vulnerabilities and they're going to get compromised. In theory signing things allows things to be de-approved after the fact when they are found to be vulnerable; in practice, well, there's all sorts of potentially explosive issues.

PS: how this interacts with virtualization makes my brain hurt. In theory I think that all virtualization systems (whether or not they require special hardware privileges) are part of the trust chain and so have to be signed. I have no idea how you enforce that.

Sidebar: the theoretical way around this with hardware support

What you need is a piece of hardware that cannot be faked, can be irreversibly disabled by the system, and is essential to boot your OS. The obvious implementation is to have a crypto processor with preloaded keys that is used to decrypt some portion of your OS. At the point where the boot system transitions out of secure booting, it tells the crypto processor to flush the preloaded keys; if your OS is booted after that point, it will be unable to decrypt portions of itself and won't run. Malware is presumed to not have the keys, so it cannot reload them into the crypto processor.

(I'm engaging in a certain amount of handwaving here about how the keys would work.)

One pragmatic difficulty with this is the question of what prevents the malware from simply providing the necessary decrypted material directly. Almost all of your OS's code and data is not system dependent and cannot be tied to a particular machine so the malware can simply carry around a generic copy of the decrypted, live version of anything that normally comes encrypted. My instinct is that it's hard to have system dependent material that is really crucial and cannot be quietly substituted or patched.