In case you don’t know what this blog is talking about: UEFI is the “Unified Extensible Firmware Interface”, and “Secure Boot” is one of its more recent features that is generating a bit of a stir in the Open Source world.
At SUSE, we have been looking at UEFI Secure Boot long and hard.
On one hand, we agree that closing down some of the loopholes in the boot process is a worthwhile goal. For decades, we have accepted that this process has been one of the soft spots that are essentially unfixable without a major change in the BIOS. Now that this change is coming, we are ready to embrace it. And we’re also happy to see a much bigger change happening as part of this, which is the establishment of UEFI as the standard firmware on all x86 platforms.
On the other hand, as a Linux company, we are seeing a number of issues that have been causing us quite some headaches, which we wanted to resolve before we publicly state our plans in this regard.
In order to explain our concerns, let’s take a brief look at what Secure Boot really does, in a nutshell. In the world of UEFI, securing the bootstrapping process means establishing a chain of trust. The “platform” is the root of this chain of trust; I tend to think of it as the motherboard and the on-board firmware ROM. Or, put slightly differently, it’s the hardware vendor, and the chain of trust flows from that hardware vendor to the component manufacturers, the OS vendors, etc.
On the legal side, this trust is established by a lot of contracts and other legal paperwork. On the level of bits and bytes, this trust is expressed via public key cryptography. The vendor puts a so-called Platform Key into the ROM, representing the root of trust. The trust relationships with operating system vendors and others is documented by signing their keys with the Platform Key.
Finally, security is established by requiring that no code will be executed by the firmware unless it has been signed by one of these “trusted” keys – be it an OS boot loader, some driver located in the ROM of some PCI Express card, or be it an update of the firmware itself.
Of course, one could make this a very long chain of trust, by requiring that everything that ever gets run on that machine be signed: the OS itself, the modules it loads, the binaries and shared libraries it loads, all the scripts executed by any random interpreter, and even
the commands you type into a shell session.
So obviously, that has to stop somewhere; and in the UEFI specification, that point is reached when the firmware hands control to the operating system. Essentially, if you want to use Secure Boot, you need to have your OS loader signed with a key trusted by the firmware, and you need the OS loader to verify that the kernel it loads can be trusted.
Admittedly, this is glossing over quite some details – but that is of no real importance for this discussion.
The crux of the matter is that this conflicts with the way the Open Source community has been developing code for several decades now. The Open Source movement began as an act of emancipation from the operating system vendors of that time. Open Source was and is about Freedom, not in a dogmatic, but really in some very practical sense. The Linux community is where it is today because people could just start their own distribution, build their own boot loader and kernel, and grow a community. It is thriving the way it is thriving today because there are thousands of people around the globe who rebuild their kernel ten times a day to fix bugs, to add enhancements, or to run their test harness on the latest set of changes. And it will only continue to thrive in this way if we keep it that way.
From this point of view, Secure Boot is very much at odds with the Linux development model.
Just for the record, I do not think this is a conspiracy, or a sinister attempt to kill Linux. That’s not going to happen. But while Secure Boot can be a significant improvement for many, it definitely creates obstacles for the Linux community.
Granted, the Windows 8 Logo certification requires that BIOS vendors should allow users to turn off Secure Boot on x86 platforms, and we have hope that all BIOS vendors will actually implement this in a way that works well for Linux developers. But ideally, Linux developers should not be required to switch off a security feature in order to run their operating system.
Thus, over the past months, our guiding questions when dealing with Secure Boot have been, how can we make it work for our customers, and how can we reconcile the requirements of Secure Boot with the needs of the Linux community.
We plan to continue this series of blog postings soon with an overview of how we intend to support Secure Boot in SUSE Linux Enterprise, and what solutions we propose to the openSUSE community.