The Linux Foundation's UEFI secure boot system
Posted Oct 10, 2012 23:47 UTC (Wed) by pjones (subscriber, #31722)
Posted Oct 11, 2012 0:50 UTC (Thu) by ebiederm (subscriber, #35028)
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.
Posted Oct 11, 2012 1:17 UTC (Thu) by mjg59 (subscriber, #23239)
Posted Oct 11, 2012 1:34 UTC (Thu) by ebiederm (subscriber, #35028)
- 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
Posted Oct 11, 2012 1:40 UTC (Thu) by pjones (subscriber, #31722)
Posted Oct 11, 2012 1:43 UTC (Thu) by mjg59 (subscriber, #23239)
(I've read the code, thanks. I wrote most of it)
Posted Oct 11, 2012 3:50 UTC (Thu) by ebiederm (subscriber, #35028)
If you can't get to the point making it an option to disable Microsofts key what is the point?
Posted Oct 11, 2012 4:14 UTC (Thu) by mjg59 (subscriber, #23239)
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.
Posted Oct 11, 2012 14:24 UTC (Thu) by jake (editor, #205)
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?
Posted Oct 11, 2012 14:28 UTC (Thu) by pjones (subscriber, #31722)
Posted Oct 11, 2012 14:40 UTC (Thu) by jake (editor, #205)
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 ...
Posted Oct 11, 2012 14:57 UTC (Thu) by mjg59 (subscriber, #23239)
Posted Oct 11, 2012 15:21 UTC (Thu) by jake (editor, #205)
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?
Posted Oct 11, 2012 15:29 UTC (Thu) by mjg59 (subscriber, #23239)
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.
Posted Oct 11, 2012 15:14 UTC (Thu) by rgmoore (✭ supporter ✭, #75)
Is there a way to change the EFI keys programatically?
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds