On October 26, Microsoft will release Windows 8. Normally, a release of
that kind would be largely uninteresting to Linux users, but Windows 8
branding brings with it
a hardware requirement that will definitely impact those wanting to use
Linux: UEFI secure boot. Distributions such as Fedora, SUSE, and Ubuntu
have been working on their plans for supporting secure boot for more than a
year now, so it may be something of a surprise that the Linux Foundation (LF)
its own entrant into the secure boot derby. But the LF "pre-bootloader" is
mostly meant as a stop-gap measure for those distributions that have yet to
on their secure boot strategy.
Secure boot is meant to protect operating systems from
pre-boot malware by cryptographically protecting the first step of the boot
process. Only binaries signed by keys stored in the UEFI firmware will be
allowed to run when secure boot is enabled—which must be the default
for certified hardware. On Windows and other systems, the first-stage
bootloader will check the signatures of the next steps, but that is not
strictly required. Since the keys stored in the firmware are under
the control of the hardware makers, it is likely that there will only be
keys from Microsoft and the manufacturer stored there. That leads to the
distasteful, but unavoidable, need to get bootloaders signed by Microsoft
in order to boot on secure-boot-enabled systems.
Much of the hue and cry surrounding secure boot has been about the need for
Microsoft-signed bootloaders, but there is little alternative. One could
imagine some kind of "Linux certificate authority" that could get its key
installed on systems, but that ship has sailed at this point—hardware
will be available soon with just the keys from Microsoft and the vendor.
Any solution for booting Linux on those systems requires a bootloader
signed by Microsoft or disabling secure boot altogether. The solutions
vary on exactly what that bootloader
The LF approach is the "smallest piece of code we could think
of" that would allow Linux to boot on Windows 8 systems, James
Bottomley, member of the LF Technical Advisory Board (TAB), said in email.
Bottomley did much of the work on what he calls the "pre-bootloader" that
will boot any Linux—signed or unsigned—using a "present user"
test. That test ensures that there is a user present at boot time. The
pre-bootloader is, of course, signed by Microsoft, but instead
of requiring a signature on the next stage of the boot process (typically a
full-blown bootloader like GRUB2), it will load and run any code if the
user at the keyboard allows it.
Beyond that, if the system is in "setup mode", the pre-bootloader will ask
the user if they want the signature of the second-stage bootloader
installed into the
database. That will allow unattended booting of the system in the future.
While it is mandatory under the certification requirements for hardware
vendors to provide a way to put systems
into setup mode (or to disable secure boot), the user interface to do so is
left unspecified. That
means there will be several—possibly many—different ways to put
systems into setup mode. In order to collect information about these
different mechanisms, the pre-bootloader will refer users to an LF web site
that will be gathering and disseminating instructions for putting systems
into setup mode.
The intent, Bottomley said, is "to ensure that smaller
distributions [have] a policy free option they could turn to as an interim
solution while they sorted our what their own security policy around
secure boot would be". The pre-bootloader binary, once signed by
Microsoft, will be available on the LF web site for anyone to use.
Distributions that don't want to have their own bootloader signed or,
indeed, participate in secure boot at all, will be able to use the
pre-bootloader for both
live distributions (on CD/DVD or USB devices) and for installations to the
hard disk. However, users will either need to get their systems into setup
mode and install the second-stage bootloader signature/hash—or be present
on every boot.
Requiring users to find and enable setup mode has a minor side benefit,
Bottomley said. The information on how to do that will be useful for
others, to either permanently disable secure boot or to install their own
keys (either in addition to the existing keys or supplanting them). For
live distribution, though, testing for user presence should not be that much of
There is an alternative to requiring systems to be put into
setup mode or for users to be at the keyboard when booting: a
pre-bootloader being used by (at least) Fedora and SUSE, called "shim".
Shim takes a different approach, but still allows distributions to set
their own policies. There are two main differences between it and the LF
pre-bootloader, though. Shim can contain an internal keyring for keys used
to sign the second-stage bootloader (or just the cryptographic hash(es) of
bootloaders), which will be checked in addition to the factory-installed
keys. In addition, in its present incarnation, shim will not provide a way
to circumvent signature/hash checking with a present user test. According
to shim developer Matthew Garrett, there is strong consideration of adding
that kind of test for removable media in support of live distributions and
installation media, though.
Even a shim that has an internal keyring can support booting binaries that
are signed by keys that don't appear on that keyring (and are not present
in the firmware). It does that by using an idea that SUSE came up with for
storing keys and hashes without requiring users to find and enable
setup mode: the "Machine Owner Key" (MOK). It turns out that the UEFI
specification provides some secure storage locations that can only be
accessed (and, importantly, changed) during the boot process. Shim uses
that storage as a place to put keys or hashes if the user directs it to,
which avoids requiring user presence on subsequent boots.
Both Fedora and SUSE will be releasing shim binaries that
contain their distribution keys on the internal keyring and are signed by
Microsoft. Because of the MOK storage idea, though, those binaries could be
used by other distributions. Even distributions that are not planning to
sign their second stage (and their kernel) could use one of the signed shims. A
recently added shim feature will add hashes (rather than just signatures)
to the MOK. So a distribution
that wants to minimize its dealings with secure boot can simply ship one of
those shims and instruct its users to store the second-stage hash in the MOK as
prompted by shim. Or those distributions can use the LF pre-bootloader.
Pre-bootloader vs. shim
That last part is a bit of a sticking point, at least for Garrett. Because
the pre-bootloader comes with an LF "stamp of approval", it may well be
seen as "the Linux solution" for secure boot. But Garrett believes that the
pre-bootloader isn't "terribly useful". All of the
functionality that it provides is also available in shim, he said, except
for the ability to "hit y and it'll run whatever you want".
Instead, shim users can just use the interface to add keys or hashes to the
MOK and boot unattended forevermore.
There are also some dangers in the LF approach, Garrett said. Because
non-technical users are easily fooled into clicking through security
warnings, the pre-bootloader could be used to attack Windows:
Users are trained to click through pretty much any security prompt that
they see, and if an attacker replaces a legitimate bootloader with one that
asks them to press "y" to make their computer work, they'll press "y". If
that bootloader then launches a trojaned Windows bootloader that launches a
trojaned Windows kernel, that's kind of a problem.
While trojaned Windows binaries aren't directly a problem for Linux, they
could be a problem for signed first-stage bootloaders. Secure boot has a
database of blacklisted keys and hashes that can be used to stop malware
from running on the system. If the LF pre-bootloader is used by some form
of malware, it could be blacklisted. That's also true of any shim
similarly used, but shim's present user "test" is a bit more complicated than
that of the pre-bootloader, so malware authors may be more inclined to
target the simpler test.
In any case, signed Linux first-stage bootloaders are clearly at some level
of risk of being blacklisted down the road. That risk is inherent in the
fact that the secure boot requirements are set by Microsoft to further its
own ends. One would guess it won't use its power over the contents of the
blacklist indiscriminately, but there is no technical obstacle to it doing
An alternative that the LF could have taken would be to create a shim with
an empty keyring and get that signed, shim developer
Peter Jones said in email. A shim built that way would only run code
signed by the keys in the firmware. Since a shim built that way wouldn't
have the key
or hash for
the second-stage bootloader available in the databases it consults, it
the second stage, but it would
prompt users to add that
key or hash to the MOK on first boot. That would allow smaller
distributions or those uninterested in signing their binaries to use
shim—and avoid the present user test (or setup mode) except for the
Garrett in particular seems irritated by the LF approach. Because of the
uncertainty on how to get systems into setup mode, he believes the
pre-bootloader risks making Linux a second-class citizen. In the comment linked above, he warned:
Linux becomes the OS that can't reboot itself. It's the OS that pops up an
ugly text entry box every time you turn your computer on. It's the OS that
asks you if you're sure you want to run potentially insecure code. 10
years of progress in making Linux accessible to users, gone.
Furthermore, he is unhappy that the LF went its own way, rather than
working with Fedora and SUSE on shim. In another comment, Garrett is
not particularly pleased with the decision to build a separate
pre-bootloader after the TAB had been urged to work together on shim:
We encouraged them to, but they felt that it was too complicated and
violated their understanding of the trust model. I obviously disagree, and
I'm obviously not impressed by the Linux Foundation picking an approach
that's at odds with 100% of the member companies who've voiced opinions on
the topic, but the Technical Advisory Board is an autonomous group with no
community oversight so there's little opportunity to influence them.
That's not quite the way Bottomley sees things, however. The LF and TAB
were "exclusively concentrating on
tools that keep linux booting and installing", with an emphasis on
the simplest solution. As he noted, "Shim was originally designed as a solution to take advantage of secure
boot and enforce a security policy rather than one that simply permits
any linux distribution to boot". As a neutral party, at least with
respect to distributions, the LF did not want to take sides on what kinds
of secure boot policies distributions should choose:
Originally we weren't sure that the distributions would be ready (or at
least that the non-major distributions would be ready) for secure boot.
Later there were disagreements between distributions over what security
policies should be enforced.
It may well turn out that the LF pre-bootloader is simply a temporary
measure and that shim can handle all of the different use cases—the
LF code uses some parts of shim, after all. Or
perhaps the simplicity of the pre-bootloader code will be attractive to
some distributions. The pre-bootloader requirement to get the system into
setup mode might be attractive to some users or distributions that want to
ensure their keys are the only ones present in the system, for example. Bottomley and the LF would be fine with any of the possible
The only LF concern is that as an organisation enabling the Linux
ecosystem, we don't want to be seen as mandating policy for taking
advantage of secure boot. If all distributions decide to adopt shim +
MOK, we'd be completely happy, but if some decide not to, that's fine
with us too.
Booting Linux on new x86 hardware is clearly going to be a bit more
difficult than it has been in the past. Due to a lot of hard work from
various folks, though, it will be a lot easier than it could have been.
In the end, there is room for both solutions, though there is merit to Garrett's
concern that the LF solution will be taken as "the Linux solution" for
secure boot. At last report, Ubuntu planned to use its own
first-stage bootloader, and other options may arise, so the "one true Linux
secure boot solution" may never really exist.
to post comments)