LSS: Secure Boot

Please consider subscribing to LWN

Subscriptions are the lifeblood of LWN.net. If you appreciate this content and would like to see more of it, your subscription will help to ensure that LWN continues to thrive. Please visit this page to join up and keep LWN on the net.

Matthew Garrett gave the opening keynote at the 2012 Linux Security Summit on his new "favorite" topic: UEFI Secure Boot. Up until about a year ago, he was working on power management for the Linux kernel, but at LinuxCon in Vancouver he found out about the requirement that systems shipping with the Windows 8 logo would be required to have Secure Boot enabled. He "ended up drinking quite a lot that week", he said, but things are not quite as bad as he had thought at first. Contrary to his initial fears, users will be able to boot Linux on hardware certified for Windows 8.

UEFI Overview

Garrett began with an overview of UEFI, noting that it is a replacement for the legacy PC BIOS. Its role is to initialize the hardware and to provide services to the bootloader for tasks like discovering hardware. It is the "least relevant 16MB of code you will ever encounter", he said. The code is mostly open and available from Intel under a BSD license. There is also some proprietary, machine-specific code to program memory controllers. The firmware vendors add their own code for "3D UIs"; those vendors also "add bugs of course". There is a surprisingly good compatibility suite and there are regular plugfests to ensure that the UEFI implementations can boot a variety of operating systems.

There are some relevant differences between UEFI and BIOS. To start with, UEFI firmware can read filesystems. The standard only requires VFAT support—and Microsoft grants a patent license for UEFI implementations. The bootloader is now an executable in PE/COFF format like Windows binaries. There is also non-volatile flash storage available where things like the location of the bootloader and parameters to pass to it can be stored.

When a computer is turned on, the firmware runs first, followed by a bootloader, which loads the operating system (OS). Traditionally, malware has targeted the OS, but vendors, particularly Microsoft, have gotten very aggressive at cutting down the OS as a target. Windows 8, for example, will load a virus checker very early on, before even some of the drivers are loaded, Garrett said.

Given that, we are seeing malware move away from the OS. Instead of "rootkits" we are starting to see "bootkits". For BIOS-based systems, the easiest way to install boot-time malware is to replace the master boot record (MBR). Once that's done, the bootloader can no longer be trusted (as the MBR will point to a malicious version), and the bootloader can change the OS when it loads it. The malware can then intercept attempts to verify the MBR by returning a "clean" copy, making it difficult to detect the compromise.

The key thing to note, Garrett said, is that if you are running untrusted code at any level, you can't trust the code at a higher level. UEFI Secure Boot is an attempt to fix the problem of bootkits. A header section is added to bootloaders (or other binaries) to contain signed hashes of the contents. The firmware will only launch binaries with a valid hash signed by a trusted key. It uses the same cryptographic algorithms that are used by Secure Sockets Layer (SSL), so there is no reason to believe that Secure Boot is insecure, other than the fact that it will be implemented by firmware vendors, he said.

Key management

For managing the keys, there are four databases in the firmware's flash. With UEFI, it will no longer be possible to write to that flash directly, instructions from x86 system management mode (SMM) will need to be used instead. The first database, "dbx", will contain keys and hashes that will always be rejected by the firmware. If a binary's hash is in dbx or if the key used to sign that hash is present, the firmware will not run it.

The "db" database contains keys and hashes that will be accepted, but entries in dbx override those in db. After the October launch of Windows 8, standard systems will contain the manufacturer's key and Microsoft's key in db. Vendors will want to enable Secure Boot so that they can access marketing money from Microsoft for promoting the hardware as "Windows 8 compatible". The margins on a laptop are "pennies", Garrett said, so the marketing money makes a big difference.

Being able to blacklist keys is an important part of the design of Secure Boot. Keys that have been used to sign malware or to sign other, non-malicious software that can be exploited can be disabled.

The other two databases are the "kek" (key exchange key), which stores keys that can be used to sign updates to db or dbx, and the "pk" (platform key) which can sign kek updates. Installing a pk causes the transition from "setup mode" to Secure Boot mode. Normally, the pk will be a hardware vendor key, which will be used to sign the update to the kek, which is where the Microsoft key will reside. This protects the vendor from Microsoft losing control of its key, because they could (in some unspecified way) have their customers update the kek using their key. If the private half of the key in the pk leaks, Secure Boot is no longer secure on those systems.

The UEFI specification defines the technical details of Secure Boot, but does not specify any particular policy with regard to how it is used. But Microsoft has specified policies for systems that want to get Windows 8 certification. For those, Secure Boot must be enabled by default, and the Microsoft key must be present. In January, Microsoft added the requirement that a physically present user must be able to disable Secure Boot and install their own keys—but only for x86-based systems, not those that are ARM-based.

An audience member asked if there was "any hope" of that requirement changing for ARM. Right now, Garrett said, ARM systems with Windows 8 certification must not allow disabling Secure Boot or adding user-specified keys. Whether ARM-based system vendors will actually pursue that certification is an open question since the Windows on ARM market "doesn't exist" at this point.

Linux on Secure Boot

To boot Linux on a Secure Boot system, there needs to be a signed bootloader. "Distasteful though it might be", the only sensible way to do that is to get Microsoft to sign it. One can set up an account with Verisign, pay some money, and get access to the Microsoft signing system. From there, you upload a binary, and a get a signed object back a day later. Because of the way headers are added with the signatures, you can still verify that it is your binary, rather than something that has been modified by Microsoft.

Once that signed bootloader has been run, it could do anything. But there are or could be consequences if it does. The signed bootloader stops malware from being inserted between the firmware and the bootloader. But, there is no way for code to determine if it is really running in Secure Boot mode. That is one difference between Secure Boot and Trusted Boot; the latter adds attestations that can prove the running code is what it says it is. In Secure Boot, one can ask the firmware if it is enabled, but there is no way to trust the answer unless the code at each level can be trusted.

In order to be able to extend trust to the higher-levels, those pieces (e.g. kernel, drivers) must be signed as well. But there is more to it than that, whatever signed kernel that runs must not be usable to run unsigned privileged code.

One of the problem areas is kexec(), which allows replacing a running kernel with a new kernel. It is like booting the new kernel, but without going through the hardware initialization (thus Secure Boot) step. But, kexec() could be used to boot Windows instead, which would allow an attacker to create a malicious Windows that boots on Secure Boot hardware. It would use the signed Linux bootloader and kernel, but kexec() into the mal-Windows. If that were to happen, Garrett said, Microsoft would blacklist the bootloader. "Apparently, our management was not enthusiastic" about that possibility, he said.

So, signed kernels require some changes to support Secure Boot. That means doing things like disallowing kexec() and restricting the ability of user space programs to cause hardware devices to perform direct memory access (DMA). The latter mostly affects graphics hardware that does not have support for kernel mode setting (KMS).

In the past, there was this idea of a separation between regular users and root. The idea was to prevent people from elevating their privileges to those of the root user, and protecting the kernel from root was not particularly important. That is no longer the case in the Secure Boot world. Root is no longer trusted, only the physically present user, who may not be the same as root, is trusted.

There are other things that will need to be handled to avoid signed kernels from "attacking" Windows. Garrett said that Kees Cook mentioned hibernation images recently as a vector for attack. When a user resumes from a suspend-to-disk, memory contents are read from disk. A crafted hibernation image could subvert the protections, so unless some other solution is found, hibernation will need to be disabled. That's fine, "because it doesn't really work in Linux anyway", he said.

Plan of attack

The plan is to create a trusted first-stage "shim" bootloader that will be signed with the Microsoft key. Because free software tends to change frequently, and it is desirable to avoid getting things signed all the time, having the shim, which should change infrequently, makes sense. The full bootloader is then signed with a distribution-specific key. Kernels and modules would also be signed with that key, or with a key already in the firmware key databases. If a user wants to sign their own kernels or modules, they can put their own key in the firmware.

Instead of adding keys to the four databases established by UEFI, SUSE came up with a way to add keys from the bootloader (which cannot access the key databases) to a secure location in the firmware. There are UEFI boot services variables that are only available to the boot environment. Using those to store keys will allow the bootloader to update them, when prompted by physically present users. Doing so from the bootloader avoids the problem of having to try to figure out and document how to add keys using the vendor-specific UEFI firmware set up tools. So far, that code does not exist, but SUSE is working on it, he said.

The management of thousands of systems requiring physically present users is "not a solved problem", he said in response to a question. There is the belief that those who are buying many systems will be able to convince vendors to ship their hardware in setup mode (with no keys) or to put custom keys into the firmware.

There are still some outstanding questions, including how to handle third-party module signing (e.g. for NVIDIA drivers). There could be some kind of Linux certificate authority (CA), but no one has stepped up to run such a thing. It would cost "at least millions" to set up and run, plus probably more than a year to get going, so "no one is jumping up and down to do this", he said. There is the possibility that third parties could have their modules signed by Microsoft or there could be some way to have the bootloader prompt for the installation of third party keys. Red Hat and other vendors are not inclined to sign third-party modules because of licensing issues and that it could be seen as an endorsement of binary-only modules.

Early on in the process of sorting out Secure Boot issues, there was concern that GPLv3 (which is the license for the GRUB2 bootloader) would require the signing keys to be disclosed. Garrett said that he and others had worked with the FSF on that problem. The conclusion that was reached is that the signing keys are not required to be disclosed as long as users can install their own keys, which they will be able to do.

In the final analysis, Secure Boot is "much less bad than it could be", Garrett said. It will increase the security of Linux "somewhat", but is mostly for increasing the security of Windows. As long as we are careful not to get our keys blacklisted (by allowing signed kernels to attack Windows), it won't seriously impede Linux in the future.

Note: you can avoid this step in the future by logging into your LWN account.