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 pre-bootloader does support such loaders – including gummiboot and efilinux – but the price is that it makes systems that use it harder to maintain.

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