UEFI secure booting

[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.

Comments

Just include the keys?

[(Anonymous)]

Isn't the simplest, and most user friendly way, to just include the (Pkek) key, so the actual owner of the hardware can decide what to sign and trust themselves?

I wonder if that isn't just required by law in some countries if the user buys and owns the hardware.

Blacklisting the Linux keys

[benanov.livejournal.com]

I'm more concerned about the blacklist than I am the whitelist.

Buy Linux Machines

[(Anonymous)]

All the more reason to stop buying Windows machines to load Linux onto them. Buy Linux machines from Linux hardware vendors.

Hardware vendors

[(Anonymous)]

I'm with you on the threat to Linux from UEFI firmware only accepting signed bootloaders, however this line is a bit of a leap for me:

"Microsoft requires that machines conforming to the Windows 8 logo program [...] ship with secure boot enabled"

So out of interest, how did you tie the Win 8 secure boot support/requirement to the logo program? Thanks.

not just Linux

[(Anonymous)]

Why single out Linux? Secure boot will not let you load Windows 7 either.

There is an explicit provision for disabling secure boot in firmware, but it can't be automated, so as not to be exploited by malware.

GPLv3 and signing keys

[(Anonymous)]

There is a lot of misunderstanding of the GPLv3 requirement for signing keys. The requirement that you provide "installation information" (which includes signing keys) applies to object code distributed for a "User Product" that is distributed AS PART OF a transaction in which the right of possession of the "User Product" changes hands.

A "User Product" is a tangible person property or goods designed for installation in a dwelling.

The gist of what GPLv3 is saying is that if you sell someone some hardware that includes GPLv3 firmware, you have to give them the keys to install new firmware of their choice.

Since Red Hat sells their software for use on other people's hardware, rather than selling their software bundled with hardware as part of the sale of that hardware, Red Hat can ship signed GPLv3 code without being obligated to provide the keys.

No OEM will sign GRUB and/or Linux

[koterpillar.myopenid.com]

No sensible one, at least. The original purpose of this is preventing boot mode rootkits... and at least GRUB lets malware writers to boot whatever they want, essentially bypassing the protection. I would assume booting Linux with a crafted userspace will let the malware do its tricks too.

Is it just me?

[https://me.yahoo.com/a/89qTkqIEmdbNn8jxOaKhYrHQIRvOCDsZ7BbB#82a37]

or it looks very like the system in place for dvd and bluray (which proved to be ineffective)?

I haven't checked the specs but if it is just an exchange of keys, it is just a matter of time before the keys are found (because people would have access to both firmware and OS), isn't it?

And what about new OS/driver versions? One machine = One OS, for life?

GPLv3

[dlitz.net]

Firstly, we'd need a non-GPL bootloader. Grub 2 is released under the GPLv3, which explicitly requires that we provide the signing keys.

No, it says this:

“Installation Information” for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source

It would suffice to provide instructions that say, "install a signed version of grub, and use that to add your own keys to the whitelist".

Well thats it for the current OEM status quo

[(Anonymous)]

Any OEM manufacturer who tries to enforce this without a hackaround will go out of business. Overnight.

Will violate European antitrust law

[(Anonymous)]

European law forbids firms from using a dominant position in one market to gain one in another. For Microsoft to extend its operating system monopoly to hardware is squarely in the frame, and if the OEMs help it they will be acting as a cartel:

http://www.lightbluetouchpaper.org/2011/09/20/trusted-computing-2-0/

We beat this seven years ago with the campaign against Trusted Computing, in which the European Commission and the German government played important roles

Kernel itself is part of the bootloader?

[(Anonymous)]

"in the near future the design of the kernel will mean that the kernel itself is part of the bootloader."

Can you please clarify what this means?

GNU ROOT CA

[(Anonymous)]

Time for the open source community to register as a root CA :)

Think about the bullshit involved in having to get your distro key signed ;)

Network boot?

[(Anonymous)]

I might be missing a trick here, but what's happening with the likes of PXE? I'm guessing that would get tied in as well?

Presumably the net boot system would have to be signed if it were present, and then I'm guessing that anything downloaded would need to be signed as well?

Lilo?

[(Anonymous)]

As Lilo is BSD licensed rather than GPL, would it be possible to have a suitably signed version of that bootloader rather than using Grub?

Hardware inside the EFI environment

[(Anonymous)]

Could someone tell me what that means?

"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 the right key is not found in the firmware, the hardware will not run at all, or will run in some limited funcionality?

[pjc50.livejournal.com]

Isn't this just the status quo on phone/tablet devices? Windows 8 is basicaly a phone/tablet OS targeted at that market. Undoubtably some of the devices will have screens and keyboards and look like desktop PCs, but will have finally abandoned the PC boot heritage. As on the mobile devices, you'll have to wait until the jailbreak becomes widely available and use that.

Don't forget that signed malware is not impossible (qv the DigiNotar CA compromise recently). It'll be entertaining once the signed malware gets in and blacklists the official Windows keys while whitelisting its own, resulting in a system where you can't remove the virus .. unless you re-jailbreak it.

[(Anonymous)]

I agree, much of the problem will be that future platforms will require a key pre-loaded before you can install a new OS or boot-loader.



Shouldn't we be getting concerned about the root signing authority? I would be very surprised if getting a key isn't restricted to either just M$ or open to anyone who will pay $MuchoDosh. In either case this new authority is what we have to work around...

linuxbios

[(Anonymous)]

Just wondering if funding or growing the linuxbios project would be a nice in. As long as a machine can have the firmware swapped out, could it not be the advantage on future hardware?

BIOS setup save the day!

[(Anonymous)]

What about going to BIOS setup and disable Secure Boot feature and install whatever you like?
Market will decide if PC sold without this BIOS feature will be well accepted by customers...
Stefano
stefano@righis.com

[dgh.livejournal.com]

It seems possible that we'll see a compromise that involves being able to disable UEFI Secure Boot in exchange for not being able to boot Windows. I.e. UEFI will have some flag that Windows can access to check whether the boot was secure or not.

Linux in the Bootloader

[(Anonymous)]

"Secondly, in the near future the design of the kernel will mean that the kernel itself is part of the bootloader"

I tried googling this to no avail. Could you cite a source for this? That sounds like an excellent way to accelerate the boot process, but I don't believe I've heard any mention of that before.

[(Anonymous)]

Red Hat, Novell and Canonical are all members of the UEFI Forum, so they're aware of secure boot too.

Why swim upstream?

[(Anonymous)]

Why fight it? Having a secure chain of trust as part of the boot system should be a security feature we embrace! We should add this feature to Linux faster than MS can ship Windows 8!

You mean the whole open source world can't work out the logistics, code, and policy to make this happen?

A lot depends on the type of device you are talking about

[(Anonymous)]

Doesn't a lot of this depend on the device you are taling about? How is this different from an Android phone (or tablet) today that has a locked boot loader? It is a part of the "package" that is sold. Clearly, a "desktop" machine should have the ability to load (i.e. disable the security of the UEFI check) other OS's - just as SOME (but not all) android phones are able to be unlocked so we can load things like CyanogenMod, etc.

BUT, there are other types of devices that are NOT going to be "open", and a MFG doesn't have the moral or legal imperative to make a device OPEN if they choose not to. YES - that will be a deciding factor for MANY, just as the choice to buy an Android over an iPhone is a choice some of us make in order to get the freedom we desire.

BUT, I agree with the last statement - DON'T PANIC...We (collectively) are smart enough to find a way to work through this, and WIN8 is at least 12 Months away (maybe more).