[coreboot] Feedback On Coreboot: the Solution to the Secure Boot Fiasco

[Patrick Georgi]

Am 2013-01-05 01:03, schrieb Andrew Goodbody:
> coreboot can never be "the Solution to the Secure
> Boot Fiasco" until it can offer better security than Secure Boot.
We do. Same level of verifiable boot (by doing signature checks on 
loaded code) without the UEFI complexity.

Microsoft made Phoenix implement ASLR and NX bit support to lock down 
the firmware some more (see UEFI plugfest slides of 2011/2012). That's 
complexity just to manage existing complexity.

And now AMI dreams of an UEFI OpenGL library (also plugfest slides).

coreboot has neither: No ASLR, but we don't run any custom code before 
jumping into the signed kernel, which can't do callbacks. No need for NX 
bit support for the same reason. No loadable modules that require 
signature checks. No resident API for operating systems (and no attack 
surface that results from this). And no plans for an OpenGL library - 
since with coreboot, firmware is long gone when OpenGL becomes 
interesting. (though someone could arguably push Linux + initrd with 
libGL.so into flash as a payload)

 From an execution stand point, our secure boot approaches are quite 
similar: signed binaries with (RSA) signature checks. The issues over 
time were similar (my prototype for such functionality in 2008 had 
TOCTOU issues, they solved similar problems in 2011). Just the signature 
formats vary.

But we aim for simplicity, which is a quality of its own - especially 
when it comes to security.


In fact, even the "Freedom" issues are similar: Google voluntarily did 
the right thing and added a user override button (hardware) to their 
chrome devices. Without that, coreboot in those systems wouldn't help a 
bit, since they'd be just as locked down as a UEFI secure boot device 
without custom key enrollment.


The issue with UEFI Secure Boot is the motivation of the guardian of 
standard and implementation. It's not Intel, it's Microsoft: They worked 
with (and/or paid) Insyde to do the secure boot implementation. They 
worked with (and/or paid) Phoenix for the ASLR/NX lock down.
And they add a bunch of requirements for hardware implementors that 
exceed the UEFI spec by way of their Windows Logo initiative.

It definitely matters right now for PC platforms where the Win8 Logo 
requirements only changed to the current state (so that they _require_ a 
key enrollment option for the user, and a way to disable secure boot) 
after public pressure.
PC is a market they control, so vendors can't ignore the Win Logo 
stuff.


Patrick