SUSE details its Secure Boot plans

SUSE engineer Vojtěch Pavlík has detailed the company's plans to implement EFI Secure Boot. The company is looking to adopt a similar approach to the one that the Fedora project wants to include in Fedora 18. According to an earlier blog post by Pavlík's colleague Olaf Kirch, the company is also planning to recommend their approach to the openSUSE project. While similar, SUSE's plans differ in key points from Fedora's and several Fedora developers have already hinted that their project might modify their approach and incorporate some changes from the SUSE plan.

The plan detailed by Pavlík sees the SUSE distribution make use of the shim bootloader developed by Fedora. SUSE plans to offer two separate versions of shim, one signed with a key provided by Microsoft (similar to Fedora's approach) and one signed with SUSE's own key. Signing shim with its own key is something that the Fedora community discounted when they formulated their Secure Boot strategy and SUSE's approach is very similar to parts of Canonical's plan for Ubuntu. The SUSE plan sees the boot process fall back to the Microsoft key on systems where a SUSE key can not be provided in the hardware.

SUSE proposes to extends the shim bootloader developed by the Fedora project
Source: SUSE

A new aspect in Pavlík's proposal is an add-on to shim that SUSE will be developing and which allows the software to load additional public keys from a separate file on the hard drive. These keys can then be used to verify GRUB and the Linux kernel further along the boot path. In Fedora's plan, these keys will be directly integrated into the shim binary which means shim has to be recompiled and re-signed whenever a new key is added.

The SUSE developers have named the public keys in this file MOKs (Machine Owner Keys). Users can add new MOKs to their system by activating a keyboard shortcut in shim to start what Pavlík calls the "enrollment process". When a new key is added, shim creates a hash of it and saves that in a "Boot Services Only" variable in the UEFI firmware. This allows shim to detect whether the keys have been tampered with.

As with Fedora's plans, the minimal shim bootloader will invoke the more flexible GRUB 2 bootloader if it has been signed with SUSE's own key or one of the MOKs. To achieve this, shim hands over the list of MOKs to GRUB. GRUB itself will then verify the integrity of the kernels it wants to boot.

The planned expansion to the way shim works is supposed to make it easier for users to boot their own kernels with Secure Boot activated. Users can simply provide their own MOKs via shim instead of having to sign shim and GRUB with their own key which then has to be loaded onto the UEFI firmware (a process that differs between hardware implementations). Another benefit of this approach is the ability to dual-boot kernels from different distributions. These can be verified by including a MOK for each distribution. This approach is easier for the user, but does counteract one of the concepts of UEFI which had been designed to facilitate dual-booting by giving the user a choice of different bootloaders at boot time.

SUSE's approach also lets users freely modify their version of GRUB 2 while still making it possible to use this modified version to boot their systems. This complies with the "anti-Tivoisation" clause in the GPLv3 and should avoid the problem of having to divulge the signing keys, which led Canonical to avoid the GPLv3-licensed GRUB 2.

Red Hat developer Matthew Garrett, who is leading the development on Fedora's Secure Boot plans, has called SUSE's implementation of the MOK file and its protection via an UEFI Boot Services Only variable "a wonderfully elegant solution." Garrett assumes that SUSE's shim extension will find its way into Fedora's boot approach since it simplifies the process, but is not saying when this would happen. Linux Foundation fellow Greg Kroah-Hartman has also stated in a post on Google+ that he likes SUSE's approach. In the meantime, Josh Boyer, who is maintaining the kernel for Fedora, has posted a long blog entry in which he summarises his experiments with Secure Boot. This post gives some insights into the specifics of Secure Boot as it affects Linux and also highlights some problems that are still being faced in this area.

See also:

• Aldi PC becomes first retail PC with UEFI Secure Boot, a report from The H.
  
• Canonical proposes alternate UEFI Secure Boot solution, a report from The H.

(fab)