LWN: Comments on "The Linux Foundation's UEFI secure boot system"

The Linux Foundation's UEFI secure boot system

mjg59 — Fri, 12 Oct 2012 05:54:26 +0000

Microsoft's certification requirements for x86 hardware mean that you're guaranteed the ability to remove Microsoft's keys and implement whatever security policy you want.

The Linux Foundation's UEFI secure boot system

jmorris42 — Fri, 12 Oct 2012 03:30:39 +0000

If you want to do those things you need to avoid buying Microsoft's hardware. Period. They used to allow their OEM partners to sell hardware that we could repurpose. Those days are ending. These efforts are simply attempts to keep some possibility of booting Linux on Microsoft PCs.

We need to always vote with our wallets for open hardware. But if want to continue to evangelize the unconverted we need these compromises to get Linux to boot in some fashion on their DRM encumbered hardware. No it won't be as clean or open as now.

The Linux Foundation's UEFI secure boot system

pjones — Fri, 12 Oct 2012 03:25:05 +0000

It's not implemented that way - basically on BIOS you call a card's UNDI driver and it implements PXE. On UEFI, the card's option ROM implements a native UEFI driver, and PXE, protocol-wise, is handled by the system's firmware. The option ROM is *also* a signed binary or it won't be loaded.

So the firmware downloads shim.efi from the server, and then it does whatever steps it needs to after that using UEFI APIs.

The Linux Foundation's UEFI secure boot system

Richard_J_Neill — Thu, 11 Oct 2012 22:37:07 +0000

How will this whole thing interact with network booting? If I set my BIOS to boot by PXE, then what? As I understand it, once the BIOS passes control to PXE, it's handed over control to the option ROM on whatever ethernet card is present...

Also, will the LXF make a version without the present user check? For example, if I wanted to boot a machine off Knoppix, and to ensure that every time after a power-cut, it would come up automatically and unattended?

Present user test

dlang — Thu, 11 Oct 2012 19:14:40 +0000

this isn't new, I heard of malware doing this to apple keyboards years ago

Present user test

Flukas88 — Thu, 11 Oct 2012 17:23:53 +0000

No, you're not.

Present user test

Cyberax — Thu, 11 Oct 2012 15:37:58 +0000

Technically, some 'programmable' keyboards now have a CPU and a decent amount of RAM and can be subverted.

The Linux Foundation's UEFI secure boot system

mpalamara — Thu, 11 Oct 2012 15:33:20 +0000

That's nice and I don't care. I don't want this feature of UEFI in hardware I use. I don't want any company or entity with access granting ability determining I what I can boot. Linux is not the only OS out there. Not good enough! Get rid of it!

The Linux Foundation's UEFI secure boot system

mjg59 — Thu, 11 Oct 2012 15:29:02 +0000

The shim design effectively has three databases to validate against:

1) The UEFI spec database (db) - this is checked in order to conform to the spec
2) The MOK database - this is checked in order to allow users to modify their trusted keys without having to use firmware-specific UI
3) A built in database - this is baked in at build time. The idea here is for the distribution to include their public key in shim when they build it, and after that shim will trust any binaries built and signed by that distribution.

So, for instance, the Fedora shim will have the Fedora key in (3). If the idea is to leave control up to the user then leaving (3) empty achieves that.

This actually allows for some interesting possibilities. If a vendor wants to set up a Linux CA (which would be expensive to do properly, and potentially open to legal risks, but it *could* be done) then they could do this by simply embedding their key in (3) and getting that copy of shim signed by Microsoft. They could then provide keys that chain back to the key in (3) to whoever was interested, using whatever policy they wanted. This is a great deal easier than getting their key into every platform's firmware, but means that an overly lax security policy could result in blacklisting by Microsoft. We'll see if anyone decides to make that happen.

The Linux Foundation's UEFI secure boot system

jake — Thu, 11 Oct 2012 15:21:03 +0000

> So what shim with an empty internal key list gets you is
> analogous to this plan

Hmm, thinking further on this, what does having an "empty internal key list" actually mean? I assume it means that something gets written to the firmware in the MOK boot variable area. Does that wipe out my existing MOK keys? or just allow unsigned booting forevermore?

I have a Fedora secure boot system installed, with its key in the MOK, now I want to boot JRandom LiveCD. It has an unsigned second-stage bootloader (GRUB2 or equivalent) and unsigned kernel. Can it use shim as its first stage? It would seem that either that would mean I lose my Fedora key in the MOK or I add an empty key that allows anything to boot thereafter. But if it uses the LF first-stage, it can boot (after I press OK) and not change the state of the system.

Or have I got that wrong?

thanks!

jake

The Linux Foundation's UEFI secure boot system

rgmoore — Thu, 11 Oct 2012 15:14:31 +0000

Is there a way to change the EFI keys programatically?

There shouldn't be a way of doing this programatically, since it undermines the whole point of the secure boot system. The goal of the system is to make sure that you can't run unsigned code without user intervention. If you could bypass the secure boot without user intervention, then malicious code could do exactly the same thing and the system would be worthless for preventing boot sector malware. The goal of all these open source approaches to secure boot is to let open source take advantage of the real benefits of the system.

Present user test

raven667 — Thu, 11 Oct 2012 15:09:18 +0000

Actually that sounds a lot like the smartcards used for satellite TV decryption. That would have been an interesting direction for the industry to go in.

Present user test

raven667 — Thu, 11 Oct 2012 15:07:18 +0000

Well, that's physically present, isn't it? Malware didn't get the ability to manifest USB devices out of thin air like in the movies last time I checked 8-).

The Linux Foundation's UEFI secure boot system

mjg59 — Thu, 11 Oct 2012 14:57:32 +0000

We're pretty reluctant to just add the "Press y to continue" code because that's something Microsoft explicitly forbid from being present in the system firmware, and there's a pretty strong incentive to be conservative. Adding the functionality would be trivial, it's really a policy thing.

Present user test

epa — Thu, 11 Oct 2012 14:52:00 +0000

I meant there is no need for manual intervention at every startup. So you can install Linux on your server without worrying about it being stuck at a menu every time it reboots.

Clearly, if you can plug in a USB key then you have physical access to the machine. The criterion for defeating malware is surely that you can't change the bootloader without physical access. Somebody with that access could equally well install a keylogger or (in principle) just replace the motherboard with a trojaned one.

In fact, you could argue that physically plugging something in is how it should have worked from the beginning. Like an old Nintendo console, your PC or tablet device could come with a Windows cartridge installed, and if you want to boot something else you have to remove that and plug in a different cartridge (which may still allow booting Windows if you wish). Unfortunately that would make the devices a couple of dollars more expensive, so we have these shenanigans with signed bootloaders instead.

Present user test

pjones — Thu, 11 Oct 2012 14:45:01 +0000

To elaborate - current generation systems don't enumerate USB in the firmware unless there's a reason to - either you've got a boot entry that points to a usb device or your software calls ReadKeyStroke()/WaitForKey()/etc. So the point at which you want to say "I'm waiting for this device to be inserted" would wind up being right after you've asked it to enumerate the USB bus. At that point, if the device is already inserted, you're still going to get a new event when it shows up. There's no distinction.

The Linux Foundation's UEFI secure boot system

jake — Thu, 11 Oct 2012 14:40:29 +0000

> So what shim with an empty internal key list gets you is analogous
> to this plan

Ah I see, thanks for the info ... does that mean that when I want to boot a LiveCD (say), I have to write stuff (even "empty" stuff) to the UEFI boot variables of the machine? Or can shim just bypass all of that and, in effect, provide the same "always present user" boot style that the LF approach takes? At some level, I guess I am asking if shim is a complete superset of the LF approach.

There may be times or reasons that someone booting doesn't want to write to the firmware of the box ...

jake

Present user test

pjones — Thu, 11 Oct 2012 14:33:30 +0000

There's no distinction at system bootup between plugging a device in and already having a device plugged in.

The Linux Foundation's UEFI secure boot system

pjones — Thu, 11 Oct 2012 14:28:04 +0000

No - that's in fact the entire point of SuSE's "MOK" system. Current shim will allow you to enroll a key or hash with physical presence during system bootup. So what shim with an empty internal key list gets you is analogous to this plan, except with this plan you have to be physically present every time, and with shim you only have to be there /once/.

The Linux Foundation's UEFI secure boot system

jake — Thu, 11 Oct 2012 14:24:09 +0000

> The Linux Foundation approach doesn't support this, and as a result is
> pretty much useless.

But, something the LF approach will do, that the shim won't (if i understand correctly), is boot an unsigned bootloader/kernel ... albeit after the user presses "OK" or whatever ... right now, for a distro that doesn't want to deal with signing their GRUB2 (or whatever) and/or their kernels, they have no way to boot in a secure-boot-enabled device.

Or am I (as usual) missing something?

jake

Present user test

gidoca — Thu, 11 Oct 2012 13:27:33 +0000

How is plugging a USB device not a manual intervention?

Present user test

pjones — Thu, 11 Oct 2012 13:21:48 +0000

No. The entire point of requiring user input - and in both cases it should be non-trivial user input - is to prove that there's a live user present. If something is deployed that wildly circumvents that, the likely outcome is that a hash of the binary in question winds up on the blacklist.

The Linux Foundation's UEFI secure boot system

vonbrand — Thu, 11 Oct 2012 12:07:43 +0000

"User's informed consent" when they have been conditioned to just click on any random carefully-designed-for-scary-look dialog that pops up, as otherwise you won't ever get anything done... Yeah, right. Check that one.

Present user test

dgm — Thu, 11 Oct 2012 09:33:03 +0000

Am I the only one that thinks that this is absurd?

Present user test

epa — Thu, 11 Oct 2012 08:11:36 +0000

It sounds like the 'present user test' consists of requiring a couple of keystrokes to select a menu item. If so, a one-dollar USB device could send the keypresses at startup, allowing you to boot the OS of your choice without manual intervention.

The Linux Foundation's UEFI secure boot system

mjg59 — Thu, 11 Oct 2012 04:18:31 +0000

Exactly. Something that requires explicit user consent (rather than the user just blindly hitting enter to make dialogs go away) is entirely reasonable here, and we've been working on solutions for that since Suse came up with an approach that make it workable.

The Linux Foundation's UEFI secure boot system

mjg59 — Thu, 11 Oct 2012 04:17:08 +0000

Really? You could have just suggested it to us, since it's something that we could have implemented without any difficulty. It just doesn't seem to be useful in the form the LF have chosen.

The Linux Foundation's UEFI secure boot system

mjg59 — Thu, 11 Oct 2012 04:14:22 +0000

The only way to modify the EFI key databases programmatically is to have access to the private half of one of the keys in the KEK database, which then allows you to produce signed updates to DB (the key and hash whitelist) and DBX (the corresponding blacklist). The only people who will typically have that are Microsoft and, perhaps, the motherboard vendor. If you want to modify those databases without having access to a key then you need to go through the firmware interface.

That's the reason for the MOK design that Suse came up with. It adds an additional key database that has different constraints, permitting users to add their own keys without having to handle different firmware UIs. I've recently added bootloader-level UI code for this (located at https://github.com/mjg59/shim/tree/mok ), which means that the end user can be prompted to enrol a new key at boot time without having to deal with firmware UI. The Linux Foundation approach doesn't support this, and as a result is pretty much useless.

The Linux Foundation's UEFI secure boot system

ebiederm — Thu, 11 Oct 2012 03:50:44 +0000

Is there a way to change the EFI keys programatically? So that you don't need to go through an EFI user interface that is likely to be different on different motherboards to change the keys?

If you can't get to the point making it an option to disable Microsofts key what is the point?

The Linux Foundation's UEFI secure boot system

geofft — Thu, 11 Oct 2012 01:58:37 +0000

Booting any random junk with the user's (informed) consent is perfectly fine. The idea is to stop booting any random junk without the user's consent.

The Linux Foundation's UEFI secure boot system

mjg59 — Thu, 11 Oct 2012 01:43:55 +0000

The model is that you'd still be booting the Microsoft signed loader. If you wanted to shift to using your own hash you'd need to rewrite the boot entry to stop running that, and then it'll stop booting if the bootloader ever gets updated since it registers the hash, not a key. This doesn't offer anything you're not already guaranteed to be able to do via the firmware.

(I've read the code, thanks. I wrote most of it)

The Linux Foundation's UEFI secure boot system

pjones — Thu, 11 Oct 2012 01:40:27 +0000

You are not reading the documentation correctly.

The Linux Foundation's UEFI secure boot system

ebiederm — Thu, 11 Oct 2012 01:34:27 +0000

If I am reading the documentation correctly getting off the windows keys can happen in two ways.

- Booting in setup gives you the option to install the key of the bootloader you are booting into EFI. Presumably that bootloader has not been signed by the Microsoft key.

- There is also another program you can run LockDown.efi that you can run in setup mode that will replace all of the EFI keys.

For more details have a look at the README

http://git.kernel.org/?p=linux/kernel/git/jejb/efitools.git;...

The Linux Foundation's UEFI secure boot system

mjg59 — Thu, 11 Oct 2012 01:17:31 +0000

How does it allow a transition away from the Microsoft keys? It depends on the loader being signed with the Microsoft key.

The Linux Foundation's UEFI secure boot system

ebiederm — Thu, 11 Oct 2012 00:50:24 +0000

The way I read it the only keyring used is the EFI keyring.

This approach looks very interesting as it allows a transition to a system without Microsoft's key, something that has been lacking in the other efi secure boot approaches I have seen so far.

Thanks James

The Linux Foundation's UEFI secure boot system

vonbrand — Thu, 11 Oct 2012 00:30:28 +0000

I guess that won't fly: This would open the door to boot any random junk.

The Linux Foundation's UEFI secure boot system

jcm — Thu, 11 Oct 2012 00:27:11 +0000

This is great news. I wondered aloud a while back about this kind of thing (the LF providing a UEFI shim) being done. It's good to see James (and presumably others) making this actually happen.

The Linux Foundation's UEFI secure boot system

pjones — Wed, 10 Oct 2012 23:47:53 +0000

Should read "and have that signed". Sorry, I was responding on my phone.

The Linux Foundation's UEFI secure boot system

pjones — Wed, 10 Oct 2012 23:18:14 +0000

I don't understand why they didn't build shim with no internal keyring, and have signed, instead of this. That provides a much more compelling system for small distros.