Securely booting Linux a "difficult" proposition

Matthew Garrett, the Red Hat engineer who originally raised the issue of UEFI Secure Boot and Linux, points out in a new posting titled "Why UEFI secure boot is difficult for Linux" that, despite Microsoft's recent changes to its UEFI Secure Boot requirements, there are some major challenges left if users want secure-booted Linux.

Microsoft recently published a Microsoft Hardware Certification Requirements document for Windows 8, which reworked an early "Logo Requirements" document from September. The new Microsoft document does address some of the initial fears about Linux being locked out on x86 systems. It now requires that it should be possible to physically disable secure boot on systems and that those systems should include a custom secure boot mode which allows keys to be added to and removed from the system's firmware. This disabling option will allow un-signed operating systems to be installed, while the custom mode, potentially, opens the way for the creation of a Linux that could be securely booted using UEFI.

But, Garrett points out that creating a Linux that could make use of secure booting is a complex proposition. "The technical implementation details are fairly straightforward", he says, "but they are not the difficult bit". One important issue would be that all code that was loaded into a signed kernel would also have to be signed. This would mean no third-party modules, such as VirtualBox or NVIDIA drivers, no out-of-tree modules and no way to build an updated driver locally. "That's going to make some people fairly unhappy" says Garrett. It would be possible to allow the kernel to load unsigned drivers but that would defeat the point of the signing process.

Garrett also returns to issues he has previously noted: that the GPLv3 requires any signed code to have its signing keys publicly published, that there is no central certifying authority for UEFI Secure Boot keys, and that it's likely that, in order to be able to get a key, an organisation would have to be a legally registered company to fulfil identity verification.

He also complains that Microsoft's new certification rules do not specify a particular user interface for the custom secure boot mode and have no description of how the key information would be distributed or any way to use custom mode for unintended installers. For users, "asking them to go into the firmware and reconfigure things adds an extra barrier" says Garrett, pointing out that Linux installations are currently as simple as putting a CD in a drive. Specifying elements in UEFI's user interface would be more likely to be addressed by the Unified EFI Forum in a future UEFI specification, rather than be mandated by Microsoft, which is a member of the forum along with AMD, American Megatrends, Apple, Dell, HP, IBM, Insyde, Intel, Lenovo and Phoenix Technologies.

The concerns over how Microsoft plans to make use of UEFI's Secure Boot on ARM processors has also continued. A number of commentators and the Software Freedom Law Center reported that Microsoft had barred ARM devices which run Windows 8 from booting Linux. These requirements are in the current Microsoft Hardware Certification Requirements document, but were known about in September 2011 when the initial fears about UEFI were raised; Microsoft's plans were detailed in presentations about its "Logo Requirements" at the time.

The basis for the argument is an expectation that ARM-based tablet makers will want Windows 8 on all their products and want the "Made for Windows 8" logo for their devices. In this scenario, all tablets, except Apple's currently market-dominating iPad and the wide range of Android tablets, would then be locked to only boot Microsoft's operating system as supplied with the device. At the moment though, Microsoft has no presence in the ARM tablet market and has yet to ship Windows 8 for ARM, while Android/ARM-based tablets, and ARM/Linux eReaders, are now established in the market. The SFLC approached the US Copyright Office in December to propose a DMCA exemption to those circumventing Secure Boot provisions. It now sees Microsoft's Secure Boot on ARM requirements as confirming its fears and as an anticompetitive use of the technology.

(djwm)