In an effort to provide additional security to Windows 8 on x86- and ARM-based devices, a new requirement for Microsoft ODMs is that all Windows 8-certified machines have the Unified Extensible Firmware Interface (UEFI) with the Secure Boot option on, creating problems for any Linux distribution that wants to run on such devices.

What is EFI?

The EFI system has slowly been making headway in recent years, and right now, EFI firmware is compatible with Windows supporting the GUID Partition Table (GPT), OS X/Intel, and Linux 2.6 and beyond machines. EFI is seen as a superior hardware/software interface to BIOS because it is platform-agnostic and runs in 32- or 64-bit mode and because GPT machines can handle boot partitions of up to 9.4 zettabytes (9.4x10²¹).

However, the benefits of EFI, and the later UEFI specification, are not particularly impressive to Linus Torvalds. As far back as 2006, Torvalds stated that many of the the EFI features were simply duplicating what BIOS had already done.

Torvalds wrote at the time. “… the problem with EFI is that it actually superficially looks much better than the BIOS, but in practice it ends up being one of those things where it has few real advantages, and often just a lot of extra complexity because of the ‘new and improved’ interfaces that were largely defined by a committee.”

Despite this disgruntlement, EFI and UEFI are supported by any kernel past 2.6, so implementing Linux on such devices is not a problem.

What is the problem is Microsoft’s other requirement for any Windows 8-certified client: The system must support Secure Boot. This hardened boot means that “all firmware and software in the boot process must be signed by a trusted Certificate Authority (CA),” according to Arie van der Hoeven, Microsoft Principal Lead Program Manager.

Red Hat developer Matthew Garrett first brought the issue to the Linux community’s attention in September 2011, when he revealed Microsoft’s plan to lock down the boot process, which Microsoft rightly points out has become a high-value target vector for injecting malware onto Windows PCs. To combat this, Microsoft will be requiring that all Windows 8 devices have the hardened boot, which means a certificate-signed operating system is the only thing that will run on such a system.

You can’t replace the UEFI system on the device with other, unencrypted, firmware. If all parts of the chain need to have a CA signature, then swapping out a machine’s signed EFI layer with, say, an unsigned BIOS or EFI would not work.

Nor is it feasible to require users to simply turn off the Secure Boot option. While technical users could easily manage this if they wanted to boot Linux on a Windows 8-certified machine, it’s still an extra step that would be less than desirable – all the more so if a user had to turn Secure Boot back on every time they wanted to boot Windows 8 on the same machine. And asking beginning users to do this would be non-optimal in the extreme.

So what are the Linux distros doing about the problem? Thus far, public statements have only been issued by the Fedora Project and Canonical for the respective Fedora and Ubuntu distros, and those proposed solutions are, perhaps predictably, different.

Fedora’s Proposed Solution

Given that their developers were among the first to point out the problem, it should be no surprise that Fedora’s team came out with the first public suggestion to work around the UEFI/Secure Boot problem.

Rather than create a Fedora-specific key that could unlock the UEFI Secure Boot feature (but only for Fedora), Garrett and his team suggested a more open two-stage bootloader approach.

After paying a one-time $99 certification fee to VeriSign for a Microsoft-signed certificate, the first-stage bootloader will have one job: boot to a second bootloader that’s signed with a Fedora key and have the second bootloader (a modified version of GRUB 2.0) roll into Fedora or whatever the user chooses.

This approach has the advantage of not letting Fedora getting a leg up over any other distro, since other distros can just pay that $99 fee for a Microsoft certificate and make their own two-stage bootloader approach.

There are other advantages. Garrett wrote: “The first stage bootloader should change very rarely, and we don’t envisage updating it more than once per release cycle. It shouldn’t be much of a burden on release management.”

Canonical’s Approach

Weeks after Fedora’s announced approach, Canonical’s founder hinted at the vendor’s solution for Ubuntu: providing an Ubuntu-specific signed key that would be accepted by Secure Boot-enabled machines.

Mark Shuttleworth wrote on the ubuntu-devel mailing list: “We’ve been working to provide an alternative to the Microsoft key, so that the entire free software ecosystem is not dependent on Microsoft’s goodwill for access to modern PC hardware.”

Two days later, the Canonical team revealed its full plans: dropping the use of the GRUB 2.0 bootloader by default on systems with Secure Boot enabled, as well as providing their own Ubuntu-signed key.

Why drop GRUB 2.0? A legal – not technical – concern that a manufacturer mistake could end up requiring Canonical to have to reveal their private key.

Ubuntu developer Steve Langasek wrote in a detailed announcement, “… in the event that a manufacturer makes a mistake and delivers a locked-down system with a GRUB 2 image signed by the Ubuntu key, we have not been able to find legal guidance that we wouldn’t then be required by the terms of the GPLv3 to disclose our private key in order that users can install a modified boot loader. At that point our certificates would of course be revoked and everyone would end up worse off.”

The Canonical solution will use one element common to Fedora: The key will be used to authorize the bootloader, not Linux itself.

For users booting from CD, a loader image signed by Microsoft’s Winqual key will chain to the UEFI bootloader efilinux, which will be signed by Ubuntu’s key, so the Winqual key won’t have to be signed every time a change is made to efilinux.

For machines with Ubuntu preinstalled, the process is similar, just more baked in. “Machines that ship as ‘Ubuntu certified’ will be required to have an Ubuntu key configured in their UEFI signature databases. The intention here is to allow these systems to receive updates for the revoked signature database, in order to be protected against known-compromised UEFI binaries,” Langasek wrote. “We are not planning to provide an alternative to Microsoft’s signing infrastructure, only an additional key; so we have no current plans to implement a signing service using the Ubuntu key.”

The Final Solution

Neither of these solutions are perfect. Fedora’s approach seems to be geared toward booting Linux on new, out-of-the-box Windows 8 machines, whereas Canonical’s method is tailored toward booting preloaded Ubuntu devices and at the same time letting the user have rights to modify the installation (exactly mirroring the Microsoft approach).

Other distros with strong desktop pursuits, notably openSUSE and Linux Mint, have yet to be heard from.

Whatever solution is used, the real requirements for solving the UEFI problem will have to walk the fine line between ease of use and not breaking a user’s machine with a faulty certificate.