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

[Patrick Georgi]

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 
itself.

> 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 
enrollment.

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 
business customers.

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).

Summary:
- 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 
Microsoft's.
I doubt that could happen, but I'll be truly happy to be proven wrong 
here.

The other option is to keep coreboot viable. Since I'm more technically 
inclined, that what I'll aim for.


Patrick