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

[Rudolf Marek]

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

So far so good. What kind of system do you prefer? Is there any particular 
system you want to see supported?  I work on Asus F2A85-M or check the wiki 
pages for other possibilites.

Thanks
Rudolf


>
> Gary
>
>
> On Sat, Jan 5, 2013 at 6:52 AM, Patrick Georgi <patrick at georgi-clan.de
> <mailto: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 <mailto:coreboot at coreboot.org>
>     http://www.coreboot.org/__mailman/listinfo/coreboot
>     <http://www.coreboot.org/mailman/listinfo/coreboot>
>
>
>
>