An update on UEFI secure boot

The "secure boot" feature that will soon be appearing in PC firmware—partly due to a mandate from Microsoft—has garnered a number of different reactions. On one hand, you have the Free Software Foundation (FSF) calling for signatures to "stand up for your freedom to install free software". On the other hand, you have pundits accusing "Linux fanatics" of wanting to make Windows 8 less secure. The truth of the unified extensible firmware interface (UEFI) secure boot situation lies somewhere in between those two extremes, as might be guessed.

The problem started to come into focus earlier this year. The UEFI specification provides for an optional "secure boot" feature that makes use of a "platform key" (PK) and "key exchange keys" (KEKs) stored in a database in firmware. The corresponding private keys would be used to sign bootloaders, drivers, and operating systems loaded from disk, removable media, or over the network. The database could also contain blacklisted keys, in the event previously valid keys are revoked because they've fallen into malicious hands.

The idea is that only signed drivers and operating systems could be loaded. This could prove a useful feature, given that it could prevent malware from infecting the signed components — but it has also been seen as a threat against open source operating systems (like Linux) and could thwart attempts to jailbreak those systems.

When LWN covered the feature in June, there was concern that "a fair amount of pressure" would be applied by proprietary OS makers to enable this feature. That concern was realized when Microsoft announced that it intended to require secure boot to award the Windows 8 logo to OEMs. Since most OEMs are going to want to qualify for this, and the marketing funds that likely accompany the program, Microsoft requiring secure boot makes it more or less mandatory.

Problems

The first and most obvious problem with secure boot is that it has the potential to only allow Microsoft operating systems to boot. As Matthew Garrett wrote in September, "A system that ships with Microsoft's signing keys and no others will be unable to perform secure boot of any operating system other than Microsoft's. No other vendor has the same position of power over the hardware vendors."

But it's more complex than simply preventing non-Microsoft operating systems from booting on hardware with UEFI secure boot enabled. In all likelihood, users will be able to boot OSes of choice for the foreseeable future. But will they actually control their own hardware?

On October 19th, Garrett provided a follow-up to his earlier posts on secure boot, and said that the problem is whether the end user will have the ability to manage their own keys:

As Garrett explains, the workaround is to turn off secure boot, but that's not very palatable:

He suggested that, rather than requiring secure boot to be disabled, it would be better to work on how the feature could be properly supported for Linux installations.

Solutions

The solution? Garrett says that a proposal has been put forward to the UEFI Forum that would allow users to install their own keys from removable media. According to Garrett, this avoids problems that would have associated with booting untrusted binaries. Because it requires removable media, malware won't be able to trigger the key installation. Instead, the system with secure boot would simply refuse to boot and fall back to system recovery procedures.

It is certainly possible that malware could infect USB keys or other removable media, but part of allowing users control is accepting some risk.

Meanwhile at the UEFI Forum

Mark Doran, president of the UEFI Forum, says that he's "trying to work with some folks in the Linux community, the Linux Foundation board for example, to see how Linux and other operating systems can participate in using this facility." He says that there are "a couple of ways that we could do that," but didn't offer specifics. Doran also said that, despite Microsoft being out front pushing for adoption, it was "absolutely intended for it to be implemented and implementable with any operating system."

Doran was also emphatic that he thought it unlikely that "many" systems would ship without the ability to turn off secure boot.

The reason is pretty simple, says Doran. Too many vendors have to support legacy Windows. At least for the foreseeable future, none of the OEMs are likely to ship systems that can't boot older versions of Windows.

This echoes what Ed Bott reported when slinging mud at "Linux fanatics". Bott asked "a spokesperson for AMI" and the response was "AMI will advise OEMs to provide a default configuration that allows users to enable / disable secure boot, but it remains the choice of the OEM to do (or not do) so." So everyone reports that it's "unlikely" that systems will ship that don't have a disable feature — but that's not quite the same as guaranteeing that users will be able to control their systems. Being able to disable secure boot is better than nothing, but that feature, alone, does not enable Linux to make use of the secure boot capability.

History Repeating Itself?

The UEFI secure boot situation is not unlike the once-feared trusted platform module (TPM) or "trusted computing" features. When first introduced, the concept for TPM was that it could provide additional system security by verifying that only authorized code could run on a system. At first glance, this seemed like a good idea — except that it could be misused to secure a system against its owner.

Microsoft and a number of other companies argued strongly in favor of TPM, while digital rights advocates argued against it. The EFF's Seth Schoen wrote in 2003:

As Schoen noted then, the EFF and others lobbied for user override, but it was initially resisted by the Trusted Computing Group (TCG). This time around, Microsoft and the UEFI Forum are saying that it's in the hands of the vendors to decide whether to implement a bypass to UEFI secure boot, and trying to downplay concerns about the implementations and the effects on users of other platforms.

Ultimately, trusted computing did not turn out to be the nightmare that many feared. We can probably thank the EFF and other organizations that lobbied against TPM that we aren't seeing widespread misuse of TPM against users.

Don't panic... yet

The worst-case scenario — a flood of "restricted boot" systems hitting the market that are incapable of booting Linux or anything other than signed Windows 8 — does seem unlikely. But we're a long way from Garrett's proposal as well. Users interested in complete control of their systems will need to keep an eye on this process, and make sure that OEMs are aware that having the ability to disable secure boot is not enough. In order to truly control your system, you must have a way to install your own trusted keys as well.