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

[gary sheppard]

And for those of us who simply do not trust Big Brother MS to forgo giving
us an Atomic Wedgie... My next system upgrade will have Coreboot if that is
even remotely possible. I prefer OPEN to Closed pretty much every time.

Gary


On Sat, Jan 5, 2013 at 6:52 AM, Patrick Georgi <patrick at georgi-clan.de>wrote:

> 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
>
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/**mailman/listinfo/coreboot<http://www.coreboot.org/mailman/listinfo/coreboot>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20130105/e07687df/attachment-0001.html>