[coreboot] Feedback On Coreboot: the Solution to the Secure Boot Fiasco
patrick at georgi-clan.de
Sat Jan 5 15:52:18 CET 2013
Am 2013-01-05 15:03, schrieb Andrew Goodbody:
> Ahh, sorry I missed that detail didn't I? That's really good to know.
It's not as obvious, since that's a payload feature, not coreboot
> And here is the crux of the issue. Distribution and management of
> keys is a major problem be it coreboot or Secure Boot.
The major issue is the (lack of) willingness of vendors to hand over
control over devices to their customers (who _bought_ the devices) like
they used to.
Key management is a minor technical detail - chrome devices have the
proper implementation (hardware switch to indicate user override), Shim
provides the best possible solution within the UEFI secureboot
framework, as long as key enrollment is at all possible.
> Agree 100%. I do not understand why people are lumping Intel in with
> Microsoft on this one.
Probably because UEFI is considered Intel's brainchild, even though
it's a huge committee these days.
> I actually find the fact that Microsoft bowed to the public outcry
> and added the requirement for key enrolment to be an encouraging
> thing. If there is a single message that is not fuelled by paranoia
> and FUD then changes can actually be made.
The other reason for allowing secure boot to be disabled is Windows 7.
And if they allow it to be disabled, it doesn't hurt to allow key
We don't know _what_ pressure made them change their mind. It's
possible that PC vendors would have refused Windows 8 Logo for 2013/2014
devices to keep Windows 7 (or even XP) compatibility around for their
If you want to discern Microsoft's actual intentions, it's best to look
at the platforms that aren't bogged down by compatibility requirements:
Win64 introduced mandantory driver signatures (since old 32bit drivers
didn't run anyway), Windows on ARM introduced mandantory Secure Boot
(with no custom key enrollment in sight).
> Just FYI MS have been controlling PC hardware since they released the
> PC98 specification so this is not a new move on their part but it is
> an escalation.
Sure, but it shows that pointing to the UEFI spec (and its siblings, PI
and so on) isn't enough. What actually happens on devices out there is
defined by Windows Logo requirements (and they're generally good ideas
even, and forced BIOS vendors to fix their code for a while now. For
example, Windows7+ explicitely tests that BIOS doesn't mess up the <1MB
RAM area on suspend/wakeup, because BIOS commonly did so).
- Verified boot processes work with coreboot and UEFI alike (within
their respective world views)
- UEFI Secure Boot is driven by Microsoft, not (as much) by Intel
- Microsoft's motivation is partly to provide a secure environment
(after their embarassing history of Windows (in)security)
- Microsoft won't shed a tear if they get away with killing competition
via "security" initiatives
- UEFI Secure Boot key management is done by the old Microsoft/Verisign
team. Probably out of convenience (they have some history of managing
driver signatures), but politically unwise any maybe malign.
So while Secure Boot is a nice idea if kept user-overrideable, it's in
the wrong hands with no existing process to resolve that (UEFI Forum is
the only semi public instance in that ecosystemen, it's paid-membership
based, and they're also not responsible for the implementation of key
management we have).
The remaining theoretical option within the UEFI ecosystem is to
pressure the UEFI Forum members to define secure boot overrides
mandantory on all device classes in all future versions of UEFI. That
way control over this dangerous feature is taken away from Microsoft and
brought into the forum, which has a broader interest base than just
I doubt that could happen, but I'll be truly happy to be proven wrong
The other option is to keep coreboot viable. Since I'm more technically
inclined, that what I'll aim for.
More information about the coreboot