[personal profile] mjg59
Since there are probably going to be some questions about this in the near future:

The UEFI secure boot protocol is part of recent UEFI specification releases. It permits one or more signing keys to be installed into a system firmware. Once enabled, secure boot prevents executables or drivers from being loaded unless they're signed by one of these keys. Another set of keys (Pkek) permits communication between an OS and the firmware. An OS with a Pkek matching that installed in the firmware may add additional keys to the whitelist. Alternatively, it may add keys to a blacklist. Binaries signed with a blacklisted key will not load.

There is no centralised signing authority for these UEFI keys. If a vendor key is installed on a machine, the only way to get code signed with that key is to get the vendor to perform the signing. A machine may have several keys installed, but if you are unable to get any of them to sign your binary then it won't be installable.

This impacts both software and hardware vendors. An OS vendor cannot boot their software on a system unless it's signed with a key that's included in the system firmware. A hardware vendor cannot run their hardware inside the EFI environment unless their drivers are signed with a key that's included in the system firmware. If you install a new graphics card that either has unsigned drivers, or drivers that are signed with a key that's not in your system firmware, you'll get no graphics support in the firmware.

Microsoft requires that machines conforming to the Windows 8 logo program and running a client version of Windows 8 ship with secure boot enabled. The two alternatives here are for Windows to be signed with a Microsoft key and for the public part of that key to be included with all systems, or alternatively for each OEM to include their own key and sign the pre-installed versions of Windows. The second approach would make it impossible to run boxed copies of Windows on Windows logo hardware, and also impossible to install new versions of Windows unless your OEM provided a new signed copy. The former seems more likely.

A system that ships with only OEM and Microsoft keys will not boot a generic copy of Linux.

Now, obviously, we could provide signed versions of Linux. This poses several problems. Firstly, we'd need a non-GPL bootloader. Grub 2 is released under the GPLv3, which explicitly requires that we provide the signing keys. Grub is under GPLv2 which lacks the explicit requirement for keys, but it could be argued that the requirement for the scripts used to control compilation includes that. It's a grey area, and exploiting it would be a pretty good show of bad faith. Secondly, in the near future the design of the kernel will mean that the kernel itself is part of the bootloader. This means that kernels will also have to be signed. Making it impossible for users or developers to build their own kernels is not practical. Finally, if we self-sign, it's still necessary to get our keys included by ever OEM.

There's no indication that Microsoft will prevent vendors from providing firmware support for disabling this feature and running unsigned code. However, experience indicates that many firmware vendors and OEMs are interested in providing only the minimum of firmware functionality required for their market. It's almost certainly the case that some systems will ship with the option of disabling this. Equally, it's almost certainly the case that some systems won't.

It's probably not worth panicking yet. But it is worth being concerned.

Re: Is it just me?

Date: 2011-09-21 01:51 pm (UTC)
From: (Anonymous)
I disagree. They depend on different cryptographic primitives.

Video discs hold encrypted content. In order to be useful to the end-user, the decryption key needs to be available somehow to the disc player. Skimming over a few levels of complexity, it is that decryption key (or the means to it) that was uncovered in DVDs and Bluray discs.

In this case, the system's security is based on signatures, not encryption. It uses asymmetric keys, not symmetric. The public key is released as part of the certificate, but the private key is not needed for end-user functionality. It is only needed to create the signatures, not check them for validity. As long as the vendor keeps the private key secure, it's foolproof, as it is mathematically impractical to forge a signature through brute force with typical key lengths.

In practice, companies fail in security all the time. Witness Diginotar. They essentially had their private key stolen due to their horrendous security practices. If BIOS vendors become the primary gatekeeper for preventing Linux from running on certain machines, they can expect to be the primary targets for black-hats looking for those private keys.

Remember Palladium? Then NGSCB and Trusted Computing? Microsoft has been trying to solve this "problem" for many years. Through TPMs and Intel's TXT, it is finally becoming a reality for them. That it makes loading Linux difficult is just a beneficial side effect for them.

Re: Is it just me?

Date: 2011-09-28 05:48 am (UTC)
From: (Anonymous)
Sorry about anonymous,
I'm Natalia Portillo (http://girlyngeek.blogspot.com) just too bored to register in ANOTHER site.

Ok, let's see.

You're right about signatures, but, PlayStation 3 used the same exact scheme.

New firmware updates required to be signed with a key really secret stored in some bunker property of Sony.

We've all seen that key run wild in Google.

It's just a matter of time and "how much fucked are we".

If all of them (or all but a marginal number of unknown chinese OEMs no one cares on) allow the option to be disabled in firmware, nothing will happen.
If almost or all of them just block everyone up to signed OSes, they will be hacked in a matter of weeks, the key will be found, leaked, or backfired (jailbreaking wPads!), and this system will be added to the list of Microsoft's failures.

So, yeah, do as mjg says, don't panic :p

Re: Is it just me?

Date: 2011-10-05 08:17 pm (UTC)
From: (Anonymous)
this is really concerning! is uefi the end of pc?

Re: Is it just me?

Date: 2012-02-16 02:44 pm (UTC)
From: (Anonymous)
I don't think so.

Just like plenty of white-box retailers sell without Windows pre-installed, I fully expect there will be either a motherboard jumper or a BIOS ROM option to disable the "feature".

There are several very important reason, not the least of which is that such a system cannot be "rescued", cannot use a memtest86 test CD, Linux LiveCD, or other diagnostics.

That's not to say that Microsoft wouldn't want it to happen that way, just that the vendors will quickly find themselves boycotted if they sell systems that cannot be serviced.

Profile

Matthew Garrett

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at Nebula. Member of the Linux Foundation Technical Advisory Board. Ex-biologist. @mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer.

Page Summary

Expand Cut Tags

No cut tags