Why Secure Boot makes people freak out.

Last week, Linus Torvalds wailed on a Red Hat developer over something called Secure Boot. He used bad words, and I’d describe the response across the community as equal parts confusion and hyperbole. This isn’t surprising. Microsoft is involved.

Unfortunately, it’s almost impossible to figure out exactly what the argument is about. The technical argument gets complex and unfamiliar to the average Linux person very, very quickly. This is frustrating to me because the issue is important. To raise the quality of the conversation a bit, I’m going to try boiling the issue down as much as I can. If I got any of this wrong, let me know in the comments.

What’s Secure Boot?

An operating system kernel like Linux is what lights up my hardware. It’s also what runs my anti-virus software and other security tools. That means that if my kernel is compromised by a hacker, I’m ruined. What’s scary is that I have no idea if that’s happening, since nobody’s watching it, assuring that it’s intact.

So we need to ensure the integrity of our software. One way to do this¹ is to digitally sign it with a digital key from someone we trust. That’s what Secure Boot allows. A “Hardware Key²” gets placed in your computer’s hardware, and if that key says your drivers and bootloader (kinda the first part of the operating system) are what they say they are, you’re in good shape. If the signatures don’t match, someone’s been messing with your stuff and the computer will shut down. Nice!

Yeah, so what’s the problem?

Well, whose Hardware Key do you trust?

Having that key installed means you trust its owner to decide what’s good and what’s bad. The owner of the Hardware Key could potentially revoke a signature or blacklist certain software, so if you want to run a device driver from “Honest John’s Driver Emporium“, and your trustworthy Hardware Key provider pulls their signature, you’re dead in the water as soon as your system gets the order.

Trusting the Hardware Key also means that you trust anyone the key’s owner trusts. That creates opportunities for attacks like Stuxnet. So when you trust the owner of the Hardware Key, you also trust the process by which they certify, validate, or authenticate the software they trust.

So while there are lots of reasons to want your software to be signed by a trusted authority, deciding which authority to trust is problematic.

For Windows users, Microsoft made that decision for you. They decided that if computer makers want to be certified with Windows 8, they must ship with Microsoft’s Hardware Key. This makes sense if you’re using Windows, but effectively prevents anything else from running on a Windows 8-certified machine unless it’s been signed with Microsoft’s key.

Gross. So all new computers will only run Windows?

No, just the Window 8-certified machines. For now, that’s mostly desktop and laptop machines, not servers or higher-end machines.

So what if I want to run something else?

First, (after a minor scandal) Microsoft changed the arrangement so that you can disable the Secure Boot feature on x86 machines if you like. You start the machine, hit F2 or ESC or F12 or whatever, and then wander through some obscure and probably buggy firmware programs to turn it off. If you’ve ever set up a password to boot your computer, it’s a little like that. If you’re on ARM machines, though, you’re out of luck: Secure Boot is mandatory.

Can I get rid of the Microsot keys?

Sure, you could install your own keys instead of Microsoft’s. The trouble is that installing keys require physical access to the system. That’s not always possible or desirable, for a variety of reasons. If you’re deploying many systems at a time, it’s downright impractical.

I don’t like any of these options.

Well, you could use the Linux Foundation’s pre-bootloader which is already signed with the Microsoft key. The LF pre-bootloader is designed to not run anything by default, but instead allows you to enter the hash
of the program you want to execute. Doing this requires you to actually sit at the keyboard and confirm that it’s OK to run the code, so we’re back to needing physical access to the system.

I really don’t like touching machines.

That leads us to the final option, which should get rid of the need to be physically present. To do this, we need to continue the chain of trust. Shim is also signed by Microsoft, just like the LF pre-bootloader, but then continues the chain of trust using either the hardware keys or a set of keys embedded in it. Since I work for them, let’s assume those embedded keys are Red Hat keys. From there, you’re off to the races: the bootloader runs, since it’s signed, and the kernel runs, since it’s also signed.

Are we done yet?

Nope!

Now that a verified copy of Linux is running, we can use the kernel’s built-in tools to verify kernel modules³. So if Secure Boot is turned on, and your kernel module is signed, you’re good to go. If it’s not signed by our key, Linux wouldn’t run it. Not even if you’re the administrator.

Now we’re done. We have a chain of trust all the way from the hardware to your kernel. This is the protection we were after in the first place — even if a virus or trojan or whatever compromises your system, it won’t be able to mess with the important parts of your system.

So what’s the big deal?

Well, we rely on Shim being signed by Microsoft, of course, and Microsoft could revoke that signature. If you were really worried about that, you could replace the Microsoft keys in your hardware or disable Secure Boot entirely. So that’s not such a big deal.

Now, what about stuff from third parties, like Honest John’s Driver Emporium? Well, this is where it gets nasty.

Red Hat won’t sign other people’s code, for the reasons we mentioned earlier. You wouldn’t and shouldn’t trust our signatures if we did. That leaves them with Microsoft’s signature.

Microsoft will sign other people’s code, but they will not sign Linux kernel modules. One solution is to have Microsoft sign Red Hat’s key, but they also refuse to sign X.509 certificates, which is how our key is put together. They will only sign Portable Executable (PE) binaries.

This brings us to the patch that started all this. The patch gets around this dilemma by allowing third parties to create a key of their own, wrap their key up as a PE binary, have it signed by the Hardware Key, and then the kernel could use the Hardware Key to verify the third party’s key and therefore trust their code. Kind of a Rube Goldberg thing, but it would work.

So what was the problem?

Not everyone thinks this is worth doing.

Not everyone thinks having a chain of trust to hardware is important. Red Hat does, because we have all kinds of customers asking for it. But even if you don’t think that’s important, you probably don’t like having to be physically in front of your system. This patch solves that.

Some think that it’s still possible to run a Microsoft-signed bootloader
alone and be done with it. Such a setup would give you no trust up the
chain, and wouldn’t require physical presence. That would be OK, but it doesn’t appear that Microsoft is willing to sign software that allows that kind of setup, as it clearly violates the primary purpose of secure boot.

Not everyone likes how we did it.

Linus is happy that we’re booting, doesn’t particularly care for the code being patched in the first place, and really really doesn’t like the idea that we’d add more code to enable a Microsoft-based chain of trust. It’s worth noting, though, that there’s nothing Microsoft-specific in the patch. It enables using any Hardware Key to validate things like third-party drivers, and doesn’t care if it came from Microsoft or somewhere else.

Red Hat also provides functionality similar to the LF pre-bootloader, so if we aren’t able to validate the bootloader, we will automatically launch a utility called mokutil, which lets you manually enter the hash of the software you want to run. Again, this means a physical presence.

A general feeling of icky-ness.

In the end, having Linux rely on Microsoft keys freaks people out. It’s a valid concern, but as Matthew Garrett points out: if you have Microsoft keys in your hardware, you already trust Microsoft. If you don’t like it, you can delete the keys, install someone else’s keys, or not buy hardware with the keys installed in the first place.

But if you want a chain of trust, you have to trust someone. Whoever you decide to trust, you may want to use their keys as the root of trust for your software, and Red Hat’s developers think you should be able to do that if you like.

That argument is actually fun to read, once you have the background. Greg KH‘s post is a good place to start.

If you’re wondering why Red Hat is trying to enable a Microsoft system for Linux oppression, I’d encourage you to think about it differently. Red Hat’s developers could have written this code, ship it in our products, and not try to send it upstream to the kernel. As Linus says in the thread, we’ve already solved the problem for our customers and partners. Instead, we’re doing what we always do: allow anyone to take advantage of the work we’ve done.

Not contributing the code would have been easier over the short-term, and definitely less contentious. But that’s not how Red Hat works. We go through great pains, and get in very public fights that show up in the Wall Street Journal, to work with our upstream projects and make things easier for our customers and our partners. There are some technical reasons for this, some business reasons, but mostly it’s the right thing to do. I think our customers, our partners, and the entire Linux community should have the chance to benefit from this work – even if it means sometimes starting an argument.

That’s probably enough for now. Despite the hyperbole, this is just an honest disagreement between engineers about the right way of providing more trust and integrity to Linux, and how we can make Linux easier to use. Matthew Garrett and others believe we should take advantage of the infrastructure we have at hand, while Linus and others believe the Microsoft-based system is flawed, and represents a threat to the agency of Linux users. The name-calling, invocations of Godwin’s Law, and everything else we’ve read this last week are just distractions from that.

Read More

• Non-technical writeup in the Wall Street Journal
• Matthew Garrett’s post on the subject. Includes bonus trolling from the increasingly silly Sam Varghese.
• Tick-tock coverage from SJVN

Thanks to David Egts for reviewing this and reminding me of the Stuxnet attack. Thanks to Eric Paris for his invaluable help in getting my head on straight in a number of ways. Thanks also to David Howells, who was good enough to take time from responding to hate mail to set me straight on the mechanics of key management, and helping me understand why all this is important in the first place.