Linux Foundation presents Secure Boot solution

The Linux Foundation and its Technical Advisory Board (TAB) have presented a plan to provide an easy way to start Linux systems where UEFI Secure Boot is active. The plan involves the very simple "loader" pre-bootloader that will be signed with a key from Microsoft. Typical Secure Boot PCs will come with the corresponding public verification key that allows them to start Windows 8 in Secure Boot mode – they should, therefore, also be able to start the mini-bootloader for Linux when Secure Boot is active, unless the Loader is included on the DBX blacklist that is maintained by the UEFI firmware.

Up to this point, the approach is similar to that of Fedora, SUSE or Ubuntu, although these distributions plan to use a "shim" pre-bootloader. Like the shim bootloader, the Linux Foundation's loader is then designed to start a full bootloader such as GRUB 2 that will boot Linux or another operating system. However, unlike the other three major distributions' solutions, the Linux Foundation's approach does not involve signing the full bootloader.

To avoid the unchallenged execution of malicious code, the mini-bootloader will ask the user whether the full bootloader can be trusted; if this is the case, and the UEFI firmware is in setup mode, the Loader will store this information in the firmware to ensure that the full bootloader will be executed without the need for any further confirmation. The mini-bootloader will offer a link to a web page that explains how to access a system's setup mode.

The Linux Foundation's approach ultimately only verifies the mini-bootloader's signature. In Ubuntu, on the other hand, the shim mini-bootloader will also check the full boot manager and only execute it if a valid signature is found. The same approach is planned for Fedora and SUSE. Unlike that of Ubuntu, these two distributions' full bootloaders will only start signed kernels.

At least in Fedora, security policies will be so strict that the components will be unable to load any unsigned modules or start another operating system (for example via Kexec) – otherwise, a Windows installation that's started this way could be made to believe that it was launched in UEFI Secure Boot, allowing malware to operate in the background. Red Hat developer Matthew Garrett fears that, without this added system security, Microsoft could place the bootloaders in question on a blacklist deployed via Windows Update, which would subsequently cause the firmware to refuse to launch the mini-bootloader required to boot Linux when Secure Boot is active.

The Linux Foundation's plans were announced by James Bottomley, who – like most members of the Technical Advisory Board – is one of the major kernel developers. Matthew Garrett, also a major kernel developer and the driving force behind Fedora's Secure Boot plans, says, in a blog post, that the loader is less useful than his own development, Shim.

In his post, Garrett also mentions that, in setup mode, the Linux Foundation's mini-bootloader only stores a hash of the full bootloader in the firmware to spare users further confirmation requests. Bottomley, on the other hand, writes in his description that the Linux Foundation's loader itself can update the signature database – however, as explained by Garrett in a forum post on LWN.net, this usually requires a key that is typically only available to Microsoft and the computer's motherboard manufacturer.

This appears to be the reason why SUSE has come up with a Shim extension that deposits verification keys in a "MOK" (Machine Owner Keys) database that can be updated by the user without the need to access the UEFI setup (the UEFI equivalent of the BIOS setup), which can vary substantially between UEFI systems. MOK support has recently been integrated into Shim. The coming months will tell which of the approaches will prevail where, and whether everything will work the way it was intended by the developers of the different approaches.

(crve)