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