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

[gary sheppard]

Rudolf,

I have been watching the Intel Haswell cpu's. The Intel GPU initiative in
linux seems pretty strong lately.

Have a good one,
Gary


On Sun, Jan 6, 2013 at 1:21 AM, Rudolf Marek <r.marek at assembler.cz> wrote:

> 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>
>>     <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/20130106/38598da4/attachment.html>