UEFI secure booting
Sep. 20th, 2011 02:01 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59Since 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.
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.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
Just include the keys?
Date: 2011-09-20 07:51 pm (UTC)I wonder if that isn't just required by law in some countries if the user buys and owns the hardware.
Re: Just include the keys?
Date: 2011-09-20 07:52 pm (UTC)Re: Just include the keys?
From: (Anonymous) - Date: 2011-09-20 08:09 pm (UTC) - ExpandRe: Just include the keys?
From:Re: Just include the keys?
From: (Anonymous) - Date: 2011-09-21 03:48 am (UTC) - ExpandRe: Just include the keys?
From: (Anonymous) - Date: 2011-09-21 05:06 pm (UTC) - ExpandDoesn't this go against the MS recommendations?
From: (Anonymous) - Date: 2011-09-23 03:23 pm (UTC) - ExpandRe: Doesn't this go against the MS recommendations?
From:Re: Just include the keys?
From: (Anonymous) - Date: 2017-02-01 08:40 pm (UTC) - ExpandBlacklisting the Linux keys
Date: 2011-09-20 07:55 pm (UTC)Re: Blacklisting the Linux keys
Date: 2011-09-22 12:44 am (UTC)Re: Blacklisting the Linux keys
From:Re: Blacklisting the Linux keys
From: (Anonymous) - Date: 2011-09-24 12:25 am (UTC) - ExpandBuy Linux Machines
Date: 2011-09-20 09:41 pm (UTC)Re: Buy Linux Machines
Date: 2011-09-20 11:22 pm (UTC)Re: Buy Linux Machines
From: (Anonymous) - Date: 2011-09-21 02:09 am (UTC) - ExpandRe: Buy Linux Machines
From: (Anonymous) - Date: 2012-02-16 02:35 pm (UTC) - ExpandRe: Buy Linux Machines
From: (Anonymous) - Date: 2011-09-21 01:23 pm (UTC) - ExpandMake it hurt: Buy Windows machines; just return them if they don't work
From:Re: Make it hurt: Buy Windows machines; just return them if they don't work
From: (Anonymous) - Date: 2011-09-21 05:19 pm (UTC) - ExpandRe: Make it hurt: Buy Windows machines; just return them if they don't work
From: (Anonymous) - Date: 2011-09-22 11:28 pm (UTC) - ExpandRe: Make it hurt: Buy Windows machines; just return them if they don't work
From:Re: Buy Linux Machines
From: (Anonymous) - Date: 2011-09-21 04:22 pm (UTC) - ExpandRe: Buy Linux Machines
From:Hardware vendors
Date: 2011-09-20 09:58 pm (UTC)"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.
Re: Hardware vendors
Date: 2011-09-20 10:05 pm (UTC)Re: Hardware vendors
From: (Anonymous) - Date: 2011-09-22 11:11 pm (UTC) - ExpandRe: Hardware vendors
From: (Anonymous) - Date: 2011-09-21 09:34 pm (UTC) - Expandnot just Linux
Date: 2011-09-20 10:00 pm (UTC)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.
Re: not just Linux
Date: 2011-09-20 10:06 pm (UTC)Re: not just Linux
From: (Anonymous) - Date: 2011-09-20 10:44 pm (UTC) - ExpandRe: not just Linux
From: (Anonymous) - Date: 2011-09-20 10:59 pm (UTC) - ExpandRe: not just Linux
From:Re: not just Linux
From: (Anonymous) - Date: 2011-09-21 03:36 am (UTC) - ExpandRe: not just Linux
From: (Anonymous) - Date: 2011-09-21 01:37 am (UTC) - ExpandRe: not just Linux
From: (Anonymous) - Date: 2011-09-21 02:29 pm (UTC) - ExpandRe: not just Linux
From: (Anonymous) - Date: 2011-09-21 07:54 pm (UTC) - ExpandRe: not just Linux
From:Re: not just Linux
From: (Anonymous) - Date: 2011-09-23 01:11 am (UTC) - ExpandGPLv3 and signing keys
Date: 2011-09-20 10:12 pm (UTC)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.
Re: GPLv3 and signing keys
Date: 2011-09-20 10:19 pm (UTC)Re: GPLv3 and signing keys
From: (Anonymous) - Date: 2011-09-20 11:08 pm (UTC) - ExpandRe: GPLv3 and signing keys
From: (Anonymous) - Date: 2011-09-21 12:12 am (UTC) - ExpandRe: GPLv3 and signing keys
From: (Anonymous) - Date: 2011-09-24 04:36 am (UTC) - ExpandRe: GPLv3 and signing keys
From:Re: GPLv3 and signing keys
From:No OEM will sign GRUB and/or Linux
Date: 2011-09-20 11:28 pm (UTC)Re: No OEM will sign GRUB and/or Linux
Date: 2011-09-21 03:50 pm (UTC)Re: No OEM will sign GRUB and/or Linux
From:Is it just me?
Date: 2011-09-21 12:01 am (UTC)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?
Re: Is it just me?
Date: 2011-09-21 01:51 pm (UTC)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?
From: (Anonymous) - Date: 2011-09-28 05:48 am (UTC) - ExpandRe: Is it just me?
From: (Anonymous) - Date: 2011-10-05 08:17 pm (UTC) - ExpandRe: Is it just me?
From: (Anonymous) - Date: 2012-02-16 02:44 pm (UTC) - ExpandGPLv3
Date: 2011-09-21 01:08 am (UTC)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".
Re: GPLv3
Date: 2011-09-21 02:22 am (UTC)Well thats it for the current OEM status quo
Date: 2011-09-21 04:44 am (UTC)Re: Well thats it for the current OEM status quo
Date: 2011-09-21 08:09 am (UTC)Consumer PCs are, of course, likely fucked.
Re: Well thats it for the current OEM status quo
From: (Anonymous) - Date: 2011-09-21 05:17 pm (UTC) - ExpandRe: Well thats it for the current OEM status quo
From: (Anonymous) - Date: 2011-09-25 07:41 pm (UTC) - ExpandWill violate European antitrust law
Date: 2011-09-21 06:26 am (UTC)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
Re: Will violate European antitrust law
Date: 2011-09-21 08:07 am (UTC)Kernel itself is part of the bootloader?
Date: 2011-09-21 06:45 am (UTC)Can you please clarify what this means?
Re: Kernel itself is part of the bootloader?
Date: 2011-09-21 07:38 am (UTC)Harald had a proposal for improving the situation: rather than add complexity to boot loaders in an attempt to keep up with the kernel, why not just boot a simple generic Linux kernel and let it deal with the rest? His idea is to create a /firstboot directory with a simple filesystem and populate it with a single Linux kernel and an initramfs image whose sole purpose is to find the real kernel and boot that. This kernel will naturally understand Linux filesystems, and it will support a user space with enough power to run whatever scripts are needed to find other bootable images on the system. Meanwhile, the initial boot loader can be made to be as simple as possible and distributions can stop messing with the MBR.
Re: Kernel itself is part of the bootloader?
From: (Anonymous) - Date: 2011-09-21 08:21 am (UTC) - ExpandRe: Kernel itself is part of the bootloader?
From: (Anonymous) - Date: 2011-09-21 01:08 pm (UTC) - ExpandRe: Kernel itself is part of the bootloader?
From: (Anonymous) - Date: 2011-09-21 09:50 am (UTC) - ExpandRe: Kernel itself is part of the bootloader?
From:Re: Kernel itself is part of the bootloader?
From: (Anonymous) - Date: 2011-09-21 03:41 pm (UTC) - ExpandRe: Kernel itself is part of the bootloader?
From:Re: Kernel itself is part of the bootloader?
From:GNU ROOT CA
Date: 2011-09-21 08:32 am (UTC)Think about the bullshit involved in having to get your distro key signed ;)
Network boot?
Date: 2011-09-21 08:33 am (UTC)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?
Re: Network boot?
Date: 2011-09-21 11:40 am (UTC)Lilo?
Date: 2011-09-21 08:55 am (UTC)Re: Lilo?
Date: 2011-09-21 11:17 am (UTC)"We" killed the Intel Processor Serial Number. "We" killed Palladium. "We" killed Trusted Computing. I'm sure "we" can kill this harebrained scheme too.
No need for contorted workarounds.
r_a_trip
Re: Lilo?
From: (Anonymous) - Date: 2011-09-21 02:36 pm (UTC) - ExpandNot a bad idea
From: (Anonymous) - Date: 2011-09-22 04:05 pm (UTC) - ExpandRe: Lilo?
From:Hardware inside the EFI environment
Date: 2011-09-21 10:12 am (UTC)"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?
Re: Hardware inside the EFI environment
Date: 2011-09-21 10:18 am (UTC)Re: Hardware inside the EFI environment
From:no subject
Date: 2011-09-21 11:17 am (UTC)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.
no subject
Date: 2011-09-21 11:35 am (UTC)Why do you think that makes it acceptable?
(no subject)
From: (Anonymous) - Date: 2011-09-21 03:57 pm (UTC) - Expandno subject
Date: 2011-09-21 02:13 pm (UTC)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...
no subject
Date: 2011-09-21 02:25 pm (UTC)linuxbios
Date: 2011-09-21 02:44 pm (UTC)Re: linuxbios
Date: 2011-09-21 02:47 pm (UTC)BIOS setup save the day!
Date: 2011-09-21 03:13 pm (UTC)Market will decide if PC sold without this BIOS feature will be well accepted by customers...
Stefano
[email protected]
Re: BIOS setup save the day!
Date: 2011-09-21 05:42 pm (UTC)Assuming the BIOS permits the option - as mentioned elsewhere, remove the feature, and that's one less thing you have to debug on your budget PC, one less thing you have to provide support for - there will be a whole new class of boot failures when Windows 8 users flip the option for whatever reason.
Even those of us who are tech-savvy are going to get *really* annoyed flipping the state every time they switch OS. I do as much work as possible in Linux but alas, my employer requires that I boot Windows fairly regularly, just to get a DHCP lease for my hardware. I also like to play games, and faffing about with Wine is not what I would call conducive to leisure. New games will probably start requiring secure boot anyway so you can't cheat.
The shame of it is, the feature has a legitimate use, and is probably a good thing for Windows users, who let's face it, need more security.
The only acceptable implementation would be one which permitted you to add keys to the keystore at boot time, in the BIOS setup, via entry of a checksum-verified key block. Then you don't need to buy a "blessed" proprietary OS just to add keys. Alas, this would be an even more serious deterrent to any casual use of Linux on a given piece of hardware.
So all in all, I wouldn't prohibit this feature - that would seem to be against the Free Software ethos, after all. And it's going to be good for Windows users. But I would mandate that any implementation also provides...
choice menu.
Re: BIOS setup save the day!
From:Re: BIOS setup save the day!
From: (Anonymous) - Date: 2011-09-22 04:39 pm (UTC) - ExpandRe: BIOS setup save the day!
From: (Anonymous) - Date: 2011-10-28 08:11 pm (UTC) - Expandno subject
Date: 2011-09-21 06:06 pm (UTC)no subject
Date: 2011-09-21 06:08 pm (UTC)(no subject)
From: (Anonymous) - Date: 2011-09-21 08:01 pm (UTC) - Expand(no subject)
From:Linux in the Bootloader
Date: 2011-09-21 06:11 pm (UTC)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.
Re: Linux in the Bootloader
Date: 2011-09-21 06:17 pm (UTC)no subject
Date: 2011-09-21 08:04 pm (UTC)Why swim upstream?
Date: 2011-09-21 11:31 pm (UTC)You mean the whole open source world can't work out the logistics, code, and policy to make this happen?
Re: Why swim upstream?
Date: 2011-09-22 12:31 am (UTC)Re: Why swim upstream?
From: (Anonymous) - Date: 2011-09-22 07:00 pm (UTC) - ExpandRe: Why swim upstream?
From:A lot depends on the type of device you are talking about
Date: 2011-09-22 12:29 am (UTC)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).
Re: A lot depends on the type of device you are talking about
Date: 2011-09-22 09:21 pm (UTC)Cause, how to develop applications this way? only throught MS Visual Studio ?