Linux Foundation ships UEFI Secure Boot workaround
Should work with any distro, but not without hassle
The Linux Foundation's open source workaround for Unified Extensible Firmware Interface (UEFI) Secure Boot has shipped, and while it's not necessarily the easiest way to boot Linux on UEFI-enabled PCs, its authors claim it should now work with any bootloader and any distribution.
The Linux community was first alerted to potential problems with Secure Boot in 2011, when computer boffins warned that the digital signing restrictions in UEFI could lock Linux out of PCs that shipped with Windows installed and the firmware security features enabled.
With Secure Boot switched on, the UEFI firmware will only boot operating systems that have been digitally signed, which is problematic for free software. In particular, software that is licensed under the GPLv3 – such as the popular Linux bootloader Grub 2 – is explicitly incompatible with Microsoft's signing scheme.
For its part, Microsoft argued that OEMs were free to allow users to disable Secure Boot, so long as those who did so understood that they were reducing the overall security of their systems. But Linux enthusiasts observed that some OEMs were actually disabling the Secure Boot switch in their firmwares, leaving customers with no way to turn it off (and thus, no way to boot Linux).
Linux kernel hackers wasted no time attacking the problem, and a number of potential workarounds were soon mooted. With the official release of the Linux Foundation's method on Friday, there are now two working techniques for booting Linux on UEFI Secure Boot machines.
The first is Matthew Garret's Shim, some variant of which is currently used by Fedora, Suse, Ubuntu, and a number of smaller Linux distros. This method has the advantage of being fairly painless for end users, while allowing small distros to support Secure Boot without dealing directly with Microsoft.
The new method proposed by the Linux Foundation is slightly more complicated than the Shim method, but it does a better job of supporting the full Secure Boot OS loading API. Specifically, Shim doesn't support the standard UEFI LoadImage() and StartImage() calls, which means some UEFI-compatible bootloaders won't work with it.
The Linux Foundation's method is based on cryptographic hashes rather than signing keys, which means that every time the kernel or bootloader for a specific machine is updated, the user must manually add the new hash for that component to the list of permitted binaries. Doing so requires being physically present at the machine, which makes this method unsuitable for servers that are managed remotely.
Some of this may change in the future, however. Garrett says he is currently working on merging the Linux Foundation's code with Shim to produce a new loader that can support both approaches – though when such a combined tool might emerge remains up in the air.
For now, Linux hackers who would like to try out the Linux Foundation's method can download the code for its loader from maintainer Jim Bottomley's website. ®
It's worth noting that although the technical issues regarding Linux and UEFI Secure Boot seem close to being fully resolved, for many Free Software advocates the ethical issues remain outstanding. Bottomley's blog post announcing the Linux Foundation's pre-bootloader spurred lively debate, with several commenters insisting that the only workaround for Secure Boot that should be encouraged is to disable it completely in the UEFI firmware. One user with the login "E Algeo" wrote:
All in all when buying PC hardware one should not be forced to be intertwined with an operating system installed on it period or it seems one has not bought the hardware but instead is renting the right to operate the hardware purchased as well.
Others viewed the release in more pragmatic terms, however. As a user going by "Gary Handslap" remarked:
The notion that achieving perfection means never compromising is such nonsense. This is a great thing, because it means that more people will be able to run the software they want on UEFI hardware.
The Reg looks forward to hearing your thoughts on the matter in Comments.