UEFI Secure Boot downgraded to PITA

Linux Foundation solution should help smaller distros

The Linux Foundation has announced its own solution to the problem of UEFI Secure Boot loading this week, a solution on its way to helping community distros and securing the future of Linux on the desktop for now.

The Linux Foundation's solution was outlined by kernel developer James Bottomley Wednesday afternoon, and details yet another variation on how to approach the Secure Boot problem.

In order to obtain the much-valued Certified for Windows 8 sticker, any Windows 8 machine will need to run the Unified Extensible Firmware Interface (UEFI) instead of the old BIOS firmware layer.

BIOS has been the firmware interface for PCs for a long time. The EFI system has slowly been making headway in recent years, and right now EFI firmware is compatible with Windows supporting the GUID Partition Table (GPT), OS X/Intel, and Linux 2.6 and beyond machines. EFI is seen as a better hardware/software interface than BIOS, since it is platform-agnostic, runs in 32- or 64-bit mode, and GPT machines can handle boot partitions of up to 9.4 zettabytes.

EFI, and the later UEFI specification, is not the problem for Linux. The problem is Microsoft's other requirement for any Windows 8-certified client: the system must support secure booting. This hardened boot means that all firmware and software in the boot process must be signed by a trusted Certificate Authority (CA).

In such a situation, any user who wanted to install Linux on a Windows 8-certified machine would be unable to accomplish the task, unless they had a signed key the UEFI secure boot system recognized, or turned Secure Boot off.

To date, Fedora, Ubuntu, and openSUSE have each come up with their own solutions to the problem, all of them variations of the same theme: a small boot-loader application that signed with a Microsoft security certificate will load into another, now trusted, boot loader like GRUB2 that will handle the rest of the boot process.

The drawbacks of this approach is that it forces Linux distribution managers to do something they might not want to do: obtain a Microsoft-signed certificate from a CA to apply to the bootloader or kernel they are shipping.

The Linux Foundation's approach is a little more self-contained: its mini-bootloader will be signed, like all the other solutions, but it will enable a hand off to any other bootloader, whether it's signed or not. If you're thinking that this would make the LF's bootloader a vector for anything to be loaded, don't worry: in order to prevent such a user from not knowing what's going on, a splash-screen will come up that will require the user to confirm that they do indeed want to install/run Linux.

If a user wants to avoid this for subsequent boots of their machine, instructions will be provided that will walk the user through the process of getting UEFI into Setup Mode, whereupon the hashes for the key can be entered into the UEFI's database thus making the new OS "legal" from Secure Boot's perspective.

Red Hat developer Matthew Garrett, who was one of the earliest coders to sound the alarm about UEFI and Linux and on the team that came up with the first solution now known as Shim, has some reservations about this approach.

"…[I]f a user switches their machine to setup mode it'll enrol [sic] the hash of the bootloader in order to avoid prompting again," Garrett wrote on his blog, "In other words, it's less useful than shim. Just use shim instead."

Apparently, in Garrett's view, updating the hashes is not a good idea because it requires users of vastly different machines to navigate similarly different UEFI interfaces in order to enter Setup Mode and get the keys entered. You can't do it automatically, he argues, because "[t]he only way to modify the EFI key databases programmatically is to have access to the private half of one of the keys in the KEK database, which then allows you to produce signed updates to DB (the key and hash whitelist) and DBX (the corresponding blacklist). The only people who will typically have that are Microsoft and, perhaps, the motherboard vendor. If you want to modify those databases without having access to a key then you need to go through the firmware interface."

Garrett's solution to the problem is to borrow elements of SUSE's solution, creating a separate key database that lets users enter their keys through a consistent interface that's more easily documented.

This argument gets to the crux of the problem for Linux: there are many ways to effectively beat the UEFI Secure Boot problem, but Linux developers are constrained by the very important requirement of making it easy enough for normal people to understand.

While Garrett dismisses the LF's approach, it does have a certain appeal for smaller distributions who were unwilling to pick up a Microsoft certificate on financial or ethical principles. This solution alleviates that need and provides an all-in-one, vendor-neutral solution to those Linux distros.

It's not perfect, but there's no reason it can't be improved. More importantly, it may finally resolve the concerns that desktop Linux would somehow get blocked from desktop and laptop PCs. It's still in pain-in-the-but territory, but it seems apparent that a solution is at hand.

Read more of Brian Proffitt's Open for Discussion blog and follow the latest IT news at ITworld. Drop Brian a line or follow Brian on Twitter at @TheTechScribe. For the latest IT news, analysis and how-tos, follow ITworld on Twitter and Facebook.

Insider: How the basic tech behind the Internet works
Join the discussion
Be the first to comment on this article. Our Commenting Policies