| |||||||||||||
The Linux Foundation's UEFI secure boot systemThe Linux Foundation's UEFI secure boot systemPosted Oct 11, 2012 14:24 UTC (Thu) by jake (editor, #205)In reply to: The Linux Foundation's UEFI secure boot system by mjg59 Parent article: The Linux Foundation's UEFI secure boot system
> 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
(Log in to post comments)
The Linux Foundation's UEFI secure boot system Posted Oct 11, 2012 14:28 UTC (Thu) by pjones (subscriber, #31722) [Link]
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 Posted Oct 11, 2012 14:40 UTC (Thu) by jake (editor, #205) [Link]
> 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
The Linux Foundation's UEFI secure boot system Posted Oct 11, 2012 14:57 UTC (Thu) by mjg59 (subscriber, #23239) [Link]
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.
The Linux Foundation's UEFI secure boot system Posted Oct 11, 2012 15:21 UTC (Thu) by jake (editor, #205) [Link]
> 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 Posted Oct 11, 2012 15:29 UTC (Thu) by mjg59 (subscriber, #23239) [Link]
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
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.
|
|||||||||||||