| |||||||||||||
Another approach to UEFI secure bootAnother approach to UEFI secure bootPosted Oct 19, 2012 11:20 UTC (Fri) by wookey (subscriber, #5501)Parent article: Another approach to UEFI secure boot
Has anyone done any work in all this to address the core issue of microsoft being the only one to put 'core keys' (whatever EUFI calls those) on systems?
If I am manufacturing hardware and don't care about running Windows on it (lets say it's not supported), but would like to be able to do Linux secure boot - can I go to the Linux Foundation for a standard key? Presumably I could add my own, but then I have to get distros to include that key in their bootloaders/kernels? Or can I just provide a corresponding signed version of shim which then separates the rest of the boot process into a different key-space.
What is the time overhead of all this dicking about through multiple bootloaders? If I'm making automotive linux I'm very interested in having secure boot working, but I also have really harsh boot-time requirements. These things seem likely to be in conflict.
(Log in to post comments)
Another approach to UEFI secure boot Posted Oct 19, 2012 16:05 UTC (Fri) by mjg59 (subscriber, #23239) [Link]
> Has anyone done any work in all this to address the core issue of microsoft being the only one to put 'core keys' (whatever EUFI calls those) on systems?
Yes.
> can I go to the Linux Foundation for a standard key?
No. It turns out to be expensive to run a CA.
> Presumably I could add my own, but then I have to get distros to include that key in their bootloaders/kernels?
The loaders don't contain keys (at least not in the sense you're talking about), but unless you've signed those loaders your firmware isn't going to boot them.
> What is the time overhead of all this dicking about through multiple bootloaders?
Minimal.
|
|||||||||||||