[coreboot] Feedback On Coreboot: the Solution to the Secure Boot Fiasco
Patrick Georgi
patrick at georgi-clan.de
Sat Jan 5 09:26:58 CET 2013
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
More information about the coreboot
mailing list