The gist of the problem is that GregKH discovered in early December that the proposed Pre-BootLoader wouldn’t work in its current form with Gummiboot. This was a bit disheartening because it meant that it didn’t fulfill the Linux Foundation mission of enabling all bootloaders. On investigation, the reason was simple: Gummiboot was created to demonstrate you could make a small and simple bootloader that takes advantage of all the services available in the UEFI platform instead of being the massive link loader that things like grub are. Unfortunately this means that it boots kernels using BootServices->LoadImage(), which means that the kernel to be booted is run through the UEFI platform secure boot checks. Originally Pre-BootLoader, like shim, was written to use PE/Coff link loading to defeat the secure boot checks. Unfortunately, this means that something run by the Pre-BootLoader must also use link loading to defeat the secure boot checks on anything it wants to load and thus, Gummiboot, which is deliberately not a link loader, won’t work under this scheme.
So time for a re-architecture and a re-write: The problem has now gone from being how do we create a Microsoft signed link loader that obeys their policies to how do we enable all children of the bootloader to use BootServices->LoadImage() in a way that obeys their policies. Fortunately, there is a way to intercept the UEFI platform signing infrastructure by installing your own security architecture protocol (See the Platform Initialization spec Volume 2 section 12.9). Unfortunately, the PI Spec isn’t actually part of the UEFI specification, but fortunately it is implemented by every Windows 8 system that I can find. The new architecture now Intercepts this protocol and adds its own security check. However, there’s a second problem: While we’re in the security architecture protocol callback, we don’t necessarily own the screen of the UEFI system, making it completely impossible to do a present user test for authorising the running of the bnary. Fortunately, there does exist a non interactive way of doing this and that’s the SUSE MOK mechanism. Thus, the Linux Foundation Pre-BootLoader has now evolved to use the standard MOK variables to store hashes of authorized binaries.
The upshot of all of this is you can now use Pre-BootLoader with Gummiboot (as demoed at LCA2013). To boot, you have to add two hashes: one for Gummiboot itself and one for the kernel you’re booting, but actually this is a good thing because now you have a single security policy controlling all of your boot sequence. Gummiboot itself has also been patched to recognise a failure due to secure boot and pop up a helpful message telling you which hash to enrol.
I’ll be doing a separate post explaining how the new architecture works (or you can read the slides), but I thought I’d better explain what’s been going on for the last month.