Linux Foundation Offers Solution for UEFI Secure Boot

Ever since news broke last year that Microsoft would require Windows 8 machines to have UEFI secure boot enabled, there were concerns that it would be used to block the installation of other operating systems, such as Linux distributions. Now, reader dgharmon sends this quote from Ars Technica about a new defense against that outcome: "The Linux Foundation has announced plans to provide a general purpose solution suitable for use by Linux and other non-Microsoft operating systems. The group has produced a minimal bootloader that won't boot any operating system directly. Instead, it will transfer control to any other bootloader — signed or unsigned — so that can boot an operating system." The announcement adds, "The pre-bootloader will employ a 'present user'; test to ensure that it cannot be used as a vector for any type of UEFI malware to target secure systems. This pre-bootloader can be used either to boot a CD/DVD installer or LiveCD distribution or even boot an installed operating system in secure mode for any distribution that chooses to use it."

Re:Virtualization

[GameboyRMH]

Not yet:

https://www.virtualbox.org/ticket/7702 [virtualbox.org]

But there's no reason it can't.

mjg59.dreamwidth.org

[bfree]

Linux Foundation approach to Secure Boot [dreamwidth.org]
James Bottomley just published a description of the Linux Foundation's Secure Boot plan [hansenpartnership.com], which is pretty much as I outlined in the second point here [dreamwidth.org] - it's a bootloader that will boot untrusted images as long as a physically present end-user hits a key on every boot, and if a user switches their machine to setup mode it'll enrol the hash of the bootloader in order to avoid prompting again. In other words, it's less useful than shim. Just use shim instead.

Further UEFI bootloader work [dreamwidth.org]
A couple of people have asked whether we're planning on implementing the Linux Foundation approach of simply asking the user whether they want to boot an unsigned file. We've considered it, but at the moment are leaning towards "no" - it's simply too easy to use to trick naive users into running untrusted code. Users are trained to click through pretty much any security prompt that they see, and if an attacker replaces a legitimate bootloader with one that asks them to press "y" to make their computer work, they'll press "y". If that bootloader then launches a trojaned Windows bootloader that launches a trojaned Windows kernel, that's kind of a problem. This could be somewhat mitigated by limiting this feature to removable media, and we're seriously considering that, but there are still some risks associated. We might just end up writing the code but disabling it at build time, and then anyone who wants to distribute with that policy can do so at their own risk.

Re:Virtualization

[lord_rob the only on]

I've installed and run Windows 8 correctly in VBOX on my Debian SID. I mean Win 8 final (RTM, not the CTP this version doesn't work).
It was just a glance at the OS though because I was expecting a real crap, and I wasn't deceived ...

Re:Unsuitable for server use?

[LordNightwalker]

From TFA:

To address this, the Linux Foundation bootloader will present its own splash screen and require user input before it actually boots. In this way, it can't be silently installed and used to hand control to a rootkit without the user's knowledge

Doesn't this mean it is unsuitable for server use - or any "headless" operation such as MythTV?

From TFA:

To facilitate repeat booting (and to make the pre-bootloader useful for booting hard disks as well as USB keys or DVDs) the pre-bootloader will also check to see if the platform is booting in Setup Mode and if it is, will ask the user for permission to install the signature of loader.efi into the authorized signatures database. If the user gives permission, the signature will be installed and loader.efi will then boot up without any present user tests on all subsequent occasions even after the platform is placed back into secure boot mode.

So they offer a solution for your problem, but user input is required for this as well.

Re:So why even bother with secure boot

[BLKMGK]

Not exactly, it was signed with a weak key produced by one of their remote desktop solutions that allowed licensing of components. Microsoft has since revoked those keys and bumped up the minimum allowed key size to stop this in the future. This was NOT a case of someone stealing a Microsoft key left in the parking lot.....

Re:just let microsoft die

[Hatta]

Apple's policies only affect Apple hardware. Microsoft is pushing this on everyone.

Re:So why even bother with secure boot

[BLKMGK]

You seem to be assuming that the root for both key paths will be the same, somehow I doubt a key used to sign apps for a remote desktop application of any flavor is going to be allowed to sign bootloaders. It also seems you do not understand exactly how the other key came about, someone didn't just steal a Private key laying around. It's not "a" key but "THE" key that's required.

You might also want to figure out that Microsoft is NOT the signing authority for the key being used here. The Microsoft key is being used only because it's a widely distributed key and Microsoft has apparently agreed to allow it's use for others but if they refuse it's possible to have the CA sign another root. Unfortunately that Public key would be far less likely to be as ubiquitous as the Microsoft key. As it stands right now I see no reason why Microsoft wouldn't allow the signing with this key, it has protections built in to prevent malicious usage.

There will be no myriad of CA signing with the Private key to be hacked, Microsoft will have their Public key distributed far and wide in hardware. They will retain the ability to sign their code and the Root will apparently be able to sign other approved code that will leverage the same Public key. This way Linux kernels COULD be signed and use this key embedded in hardware if desired. Some distro are apparently looking to go that way. However kernels change and are sometimes custom so this shim was created and will be signed by this group to sidestep the hassle. They are getting signed by a key given to them that descends from the Microsoft key. I would bet that a revocation process does exist but I doubt it's a very smooth one.

Note that Verisign not Microsoft gets the fees from this process, they are the CA handling this.