SUSE Linux Outlines Its Plans for Windows 8 Secure Boot

Well the Secure Boot saga keeps going on and on as Linux distributions far and wide decide how they’re going to work around Windows 8’s planned restrictions, and this week we heard from yet another project.

It was SUSE Linux to speak out this time, and what it has proposed amounts in many ways to a hybrid approach between what we’ve already seen from Ubuntu and Fedora.

“UEFI Secure Boot is a useful technology, making it harder for attackers to hide a rootkit in the boot chain,” began Olaf Kirch, director of the SUSE Linux Enterprise department in SUSE Engineering, in a blog post on Wednesday. “At the same time, already the basics of its operation–establishing a single root of trust–conflict with the principles of Open Source development, which must be independent and distributed to work.”

‘It’s a Smart Solution’

For those who missed it, Windows 8’s Unified Extensible Firmware Interface (UEFI) will stipulate that only operating systems with an appropriate digital signature can boot. Both the Free Software Foundation and the Linux Foundation have weighed in with their own views on the matter.

Yet there are two ways of working around those restrictions, Kirch explained.

“One is to work with hardware vendors to have them endorse a SUSE key which we then sign the boot loader with,” he explained. “The other way is to go through Microsoft’s Windows Logo Certification program to have the boot loader certified and have Microsoft recognize our signing key.”

SUSE plans to use the shim loader originally developed by Fedora, Kirch said: “It’s a smart solution which avoids several nasty legal issues, and simplifies the certification/signing step considerably,” he explained.

That shim loader will load the GRUB 2 boot loader, verify it, and then load kernels signed by a SUSE key.

Two Keys Possible

On Thursday, however, Vojtěch Pavlík, director of SUSE Labs, offered more detail.

“We start with a shim, based on the Fedora shim, signed by either a certificate signed by the SUSE KEK [Key Exchange Key] or a Microsoft-issued certificate, based on what KEKs are available in the UEFI key database on the system,” Pavlík explained.

In other words, two separate versions of the shim will be possible: one signed with SUSE’s own key, similar to Ubuntu’s approach, and one signed with a key provided by Microsoft, much as in Fedora’s strategy.

Either way, the shim will verify that the GRUB 2 boot loader is trusted using by default an independent SUSE certificate embedded in its body. In addition, however, the shim will also allow “Machine Owner Keys” (MOKs) to override the default SUSE key, Pavlík explained.

‘A Wonderfully Elegant Solution’

So, “GRUB 2, once loaded and verified by the shim, will call back to the shim when it wants to verify the kernel–to avoid duplication of the verification code,” he added. “The shim will use the same list of MOKs for this and tell GRUB 2 whether it can load the kernel.”

Because MOKs constitute a list and not just a single key, “you can make the shim trust keys from several different vendors, allowing dual- and multi-boot from the GRUB 2 boot loader,” Pavlík concluded.

Implementation, of course, may prove more complicated, he added. Still, of paramount importance is that “you can freely modify GRUB2 and your kernel as an owner of a machine” as well as the fact that “the machine didn’t get tivoized,” he noted.

Red Hat developer Matthew Garrett–who originally called attention to all this back in September–has called SUSE’s approach “a wonderfully elegant solution.” In fact, “I suspect that we’ll adopt this approach in Fedora as well,” he said in a blog post on Friday.

I’m sure this isn’t the last update, however, and it remains to be seen what route openSUSE will take. When more is announced, I’ll keep you posted.