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.
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:
Every approach that involves us signing with a trusted key comes with
associated problems. There's also a common problem with all of them —
you only get to play if you have your own trusted key. Corporate Linux
vendors can probably find a way to manage this. Everyone else (volunteer or
hobbyist vendors, end users who want to run their own OS, anyone who wants
to use a modified bootloader or kernel) is shut out.
As Garrett explains, the workaround is to turn off secure boot, but
that's not very palatable:
It benefits nobody for Linux installation to require disabling a legitimate
security feature. It's also not likely to be in a standard location on all
systems and may have different naming. It's a support nightmare.
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
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
The only way it could get on the system would involve the user explicitly
booting off removable media, which would be a significant hurdle. If you're
at that stage then you can also convince the user to disable secure boot
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
I would challenge you to find one of the theoretical systems that has no
disable [feature]. I've taken a pretty good temperature, and I can't find
anybody that's planning to build a system with no enable/disable feature,
with the exception of kiosks.
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
The TCPA [Trusted Computing Platform Alliance] security design allows
software publishers to [...] create encrypted network protocols and file
formats — with keys tucked away in hardware rather than accessible in
memory. Thus, the same security features that protect your computer and its
software against intruders can be turned against you.
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.
to post comments)