Fedora, secure boot, and an insecure future

This article brought to you by LWN subscribers Subscribers to LWN.net made this article — and everything that surrounds it — possible. If you appreciate our content, please buy a subscription and make the next set of articles possible.

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 described 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.

Fedora's plan

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 interesting questions.

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; what if 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.

Why bother?

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 to.

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 freedom in terms of users not being able to produce their own 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.

Alternatives?

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.

