The UEFI secure boot mechanism has been the source of a great deal of
concern in the free software community, and for good reason: it could
easily be a mechanism by which we lose control over our own systems.
Recently, Red Hat's Matthew Garrett
how the Fedora
distribution planned to handle secure boot in the Fedora 18 release.
That posting has inspired a great deal of concern and criticism, though,
arguably, about the wrong things.
On a system with secure boot enabled, the hardware will refuse to run any
system that has not been signed by a key it recognizes. Secure boot is
meant to be a way to thwart boot-time malware by ensuring that only trusted
(and unmodified) software gains control of the system. It is not
effective as a digital rights management (DRM) mechanism; if you can gain
control of the system, it is relatively easy to fool an operating system
into thinking that secure boot is in effect when it is not. Providing the
degree of control needed for effective DRM requires a trusted platform
module (or similar) and associated software.
Secure boot does
offer some hope of preventing a system from booting if its bootloader or
kernel have been compromised by malware, though, as the "Flame" malware
shows, there are limits to how much one can rely on signatures to keep
systems secure. Secure boot could also, unfortunately, be effective in
preventing booting if the user has tried to install an operating system of
his or her choice.
The Windows 8 logo requirements specify that secure boot must be enabled.
After some pushback, the requirements have been amended to also say that it should be possible
for the owner of a system to disable secure boot or install new keys. It
does not say that these actions need to be easy to carry out,
though. Given that changing secure boot is a firmware-level operation,
users wanting to make changes will be subjecting themselves to the very
best sort of user experience that can be created by BIOS developers. It
would be entirely unsurprising, for example, if users were forced to
hand-enter new keys as long hex strings. For this to be an unpleasant and
error-prone process would not be surprising.
Developers in the Fedora camp have evidently come to the conclusion that
they do not want to force their users to endure such an experience to be
able to install Fedora on their systems. So Fedora has chosen to take a
different approach. Availing themselves of the Microsoft developer
program, they will purchase a Microsoft-signed key for $99, then use that
key to sign a minimal bootloader. UEFI-enabled hardware will then consent
to boot that bootloader, which will immediately turn around and boot a
special version of the GRUB2 bootloader which, in turn, will boot the Fedora
kernel. A Fedora system set up in this mode should boot on a system with
secure boot enabled with no changes required.
The appeal of this solution is clear: Fedora will "just work" on UEFI
systems without forcing (possibly highly non-technical) users to make scary
firmware-level changes. But there is a down side as well. The signed
bootloader must ensure that it only runs GRUB2 if the GRUB2 binary has been
signed by Fedora (using its own key at this point), and GRUB2 will only boot
kernels that have been signed by Fedora. GRUB2 will need to be locked down,
and the kernel too; the kernel will, for example, only be able to load
modules that bear Fedora's signature. Given that, Red Hat's persistent
attempts to get signed module enforcement into the kernel despite some interesting resistance make more sense.
Much of the coverage of this plan in the mainstream media bore headlines
like "Red Hat to pay Microsoft for the right to run Linux." Such headlines
are not strictly true; the payment ($99 total) evidently goes to Verisign,
and what is really being paid for is the ability to boot Linux with a
minimum of UEFI-caused user inconvenience. The payment for a
Microsoft-signed key raises eyebrows, but it is evidently seen as the best
response to a bad situation.
And perhaps that is just what it is. But it also raises a number of
A good idea?
For example: what guarantees exist that a Microsoft-signed key will
continue to be available in the future for a reasonable price? If secure
boot takes over, and the only universally-recognized keys are those signed
by Microsoft, then Microsoft will have a monopoly on the right to boot an
operating system on future hardware. Corporations are, in general, not
known for a principled refusal to exploit that kind of position, and this
corporation, in particular, is well known indeed for the opposite sort of
behavior. One can only assume that the price of such keys would increase
in this situation.
Microsoft will also have the right to revoke keys if they can be said to be
a threat to the promises given by the secure boot mechanism. That is why
Fedora must be careful to limit anything that enables direct access to the
hardware; should somebody be able to get such access, the signed Fedora
system could be used to attack Windows systems that have secure boot
enabled. In theory, all it would take is a kernel security hole to enable
this sort of attack; that could then cause the Fedora key to be revoked. A
quick check shows about 20 kernel security updates issued by Fedora since
the beginning of this year, with multiple vulnerabilities fixed in most.
That could lead to a lot of key churn, especially if, as Alan Cox suggests, every kernel hole will require that
its certificate be revoked.
Depending on what software is run on a specific system (if it dual-boots
Windows and Linux, for example), a revoked key could
find itself into the system's "forbidden signatures" database. That would
immediately disable the booting of the signed Fedora image, essentially
crippling the machine. The amount of joy resulting from such an outcome
can be expected to be small.
Some developers have argued that Fedora's
plan is a violation of the GNU General Public License, or, at least, of the
Fedora project's own guidelines, despite Fedora's efforts to ensure that
users retain as much freedom as possible. GPL enforcement actions in this
case seem unlikely; there's no shortage of much more severely locked-down
Linux systems out there, and they have not been the target of such actions
thus far. But there is a definite risk of damage to the Fedora project's
image as users discover that they cannot easily install their own kernels,
add third-party modules, or run tools like SystemTap.
Finally, there is the risk that Fedora's plan will legitimize the UEFI
secure boot mechanism. For now secure boot can be disabled on x86 systems;
Microsoft, in the future, points to Fedora 18 as an example of how
everybody is able to work within the secure boot system and tries to make
secure boot mandatory? Thus, some argue, Fedora is giving aid and comfort
to those who would most like to take control of our systems away from us.
Given all of this, one might well wonder why Fedora is pursuing this path.
Fedora users are not generally known to clamor for locked-down systems that
they cannot easily tweak. Without any inside information whatsoever, your
editor suggests that there are two entirely plausible reasons for Fedora's
attempt to work with secure boot:
- The Fedora project, like many free software projects, would like to
have a wider base of users. It fears that, in the absence of a "just
works" experience on upcoming hardware, it will lose users to other
distributions that might be more willing to make that effort. Some of
those users may be lost to Linux altogether.
- The plan starts with a disclaimer that it is not representative in any
way of Red Hat's intentions for its enterprise distribution. But it seems
clear that there could be actual customer demand for a version of RHEL
that runs in the secure boot environment. If one embraces the sort of
restrictions that come with enterprise support, the additional rules
imposed by secure boot will have a minimal impact, while the apparent
benefits are clear. Fedora's role is, among other things, to test out
technologies that might go into RHEL; in this case, Fedora's users get
to stumble into the secure boot land mines so RHEL users don't have
So Fedora's decision to take this approach is not all that surprising. The
project has concluded that it is better to restrict user freedom in certain
settings to make their life easier in other ways; as Matthew Garrett put it:
[T]here's no way to rationally say that the loss of
signed bootloader or kernel for free is more or less significant
than the benefit of having an operating system that users can
install without firmware reconfiguration.
For those who do think that the loss of freedom inherent in the Fedora
scheme is unacceptable, the time between the present and when
Windows 8 hardware
starts shipping would be an ideal opportunity to demonstrate better
alternatives. But it's not clear what those would be.
One could simply ignore secure boot, requiring users to disable it before
they can install Linux on their machines. That imposes a potentially scary
or difficult task on those users; by the specification, secure boot cannot
be disabled by the software directly. There may also be resistance from
users who see a switch saying "turn off security" and don't want to flip
it. This approach will work fine for hard-core Linux users and developers,
but seems certain to lose other kinds of users.
An alternative would be to attempt to gain more control of the situation at
the hardware level. An example can be seen in Google, which has made a
point of ensuring that unlockable Android handsets exist and are available
at a reasonable price. Hardware designed to run ChromeOS also, by design,
comes with an easily-toggled physical switch that turns off the boot-time
checks for users wanting to install their own software. The level of
interest in "jailbreaks" for locked-down handsets shows that a lot of users
do see value in having full control over the hardware they own. Open (and
"open source") hardware has a following; it may be that the only real way
to remain in control is to work to ensure that this kind of hardware
continues to exist and has a growing market share. There should be a
business opportunity here; projects like the Vivaldi tablet show that some people see
that opportunity and are trying to pursue it.
In the absence of open hardware, we will continue to be at the mercy of
others whose interests are unlikely to be the same as ours (for just about
any value of "ours"). That will leave us in a position where attempts to
cope like what we're seeing with Fedora seem like the best options
available. That does not seem like the path to freedom; it is not why we
have spent decades developing free operating systems. Fedora's secure boot
plan may be an effective workaround, but leaves the real bug unfixed.
to post comments)