<div dir="ltr"><div><div><div>Rudolf,<br><br></div>I have been watching the Intel Haswell cpu's. The Intel GPU initiative in linux seems pretty strong lately.<br><br></div>Have a good one,<br></div>Gary<br></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Sun, Jan 6, 2013 at 1:21 AM, Rudolf Marek <span dir="ltr"><<a href="mailto:r.marek@assembler.cz" target="_blank">r.marek@assembler.cz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
And for those of us who simply do not trust Big Brother MS to forgo giving us an<br>
Atomic Wedgie... My next system upgrade will have Coreboot if that is even<br>
remotely possible. I prefer OPEN to Closed pretty much every time.<br>
</blockquote>
<br></div>
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.<br>
<br>
Thanks<br>
Rudolf<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
Gary<br>
<br>
<br>
On Sat, Jan 5, 2013 at 6:52 AM, Patrick Georgi <<a href="mailto:patrick@georgi-clan.de" target="_blank">patrick@georgi-clan.de</a><br></div><div><div class="h5">
<mailto:<a href="mailto:patrick@georgi-clan.de" target="_blank">patrick@georgi-clan.de</a><u></u>>> wrote:<br>
<br>
Am 2013-01-05 15:03, schrieb Andrew Goodbody:<br>
<br>
Ahh, sorry I missed that detail didn't I? That's really good to know.<br>
<br>
It's not as obvious, since that's a payload feature, not coreboot itself.<br>
<br>
<br>
And here is the crux of the issue. Distribution and management of<br>
keys is a major problem be it coreboot or Secure Boot.<br>
<br>
The major issue is the (lack of) willingness of vendors to hand over control<br>
over devices to their customers (who _bought_ the devices) like they used to.<br>
<br>
Key management is a minor technical detail - chrome devices have the proper<br>
implementation (hardware switch to indicate user override), Shim provides<br>
the best possible solution within the UEFI secureboot framework, as long as<br>
key enrollment is at all possible.<br>
<br>
<br>
Agree 100%. I do not understand why people are lumping Intel in with<br>
Microsoft on this one.<br>
<br>
Probably because UEFI is considered Intel's brainchild, even though it's a<br>
huge committee these days.<br>
<br>
<br>
I actually find the fact that Microsoft bowed to the public outcry<br>
and added the requirement for key enrolment to be an encouraging<br>
thing. If there is a single message that is not fuelled by paranoia<br>
and FUD then changes can actually be made.<br>
<br>
The other reason for allowing secure boot to be disabled is Windows 7. And<br>
if they allow it to be disabled, it doesn't hurt to allow key enrollment.<br>
<br>
We don't know _what_ pressure made them change their mind. It's possible<br>
that PC vendors would have refused Windows 8 Logo for 2013/2014 devices to<br>
keep Windows 7 (or even XP) compatibility around for their business customers.<br>
<br>
If you want to discern Microsoft's actual intentions, it's best to look at<br>
the platforms that aren't bogged down by compatibility requirements: Win64<br>
introduced mandantory driver signatures (since old 32bit drivers didn't run<br>
anyway), Windows on ARM introduced mandantory Secure Boot (with no custom<br>
key enrollment in sight).<br>
<br>
<br>
Just FYI MS have been controlling PC hardware since they released the<br>
PC98 specification so this is not a new move on their part but it is<br>
an escalation.<br>
<br>
Sure, but it shows that pointing to the UEFI spec (and its siblings, PI and<br>
so on) isn't enough. What actually happens on devices out there is defined<br>
by Windows Logo requirements (and they're generally good ideas even, and<br>
forced BIOS vendors to fix their code for a while now. For example,<br>
Windows7+ explicitely tests that BIOS doesn't mess up the <1MB RAM area on<br>
suspend/wakeup, because BIOS commonly did so).<br>
<br>
Summary:<br>
- Verified boot processes work with coreboot and UEFI alike (within their<br>
respective world views)<br>
- UEFI Secure Boot is driven by Microsoft, not (as much) by Intel<br>
- Microsoft's motivation is partly to provide a secure environment (after<br>
their embarassing history of Windows (in)security)<br>
- Microsoft won't shed a tear if they get away with killing competition via<br>
"security" initiatives<br>
- UEFI Secure Boot key management is done by the old Microsoft/Verisign<br>
team. Probably out of convenience (they have some history of managing driver<br>
signatures), but politically unwise any maybe malign.<br>
<br>
So while Secure Boot is a nice idea if kept user-overrideable, it's in the<br>
wrong hands with no existing process to resolve that (UEFI Forum is the only<br>
semi public instance in that ecosystemen, it's paid-membership based, and<br>
they're also not responsible for the implementation of key management we have).<br>
<br>
The remaining theoretical option within the UEFI ecosystem is to pressure<br>
the UEFI Forum members to define secure boot overrides mandantory on all<br>
device classes in all future versions of UEFI. That way control over this<br>
dangerous feature is taken away from Microsoft and brought into the forum,<br>
which has a broader interest base than just Microsoft's.<br>
I doubt that could happen, but I'll be truly happy to be proven wrong here.<br>
<br>
The other option is to keep coreboot viable. Since I'm more technically<br>
inclined, that what I'll aim for.<br>
<br>
<br>
Patrick<br>
<br>
<br>
--<br></div></div>
coreboot mailing list: <a href="mailto:coreboot@coreboot.org" target="_blank">coreboot@coreboot.org</a> <mailto:<a href="mailto:coreboot@coreboot.org" target="_blank">coreboot@coreboot.org</a>><br>
<a href="http://www.coreboot.org/__mailman/listinfo/coreboot" target="_blank">http://www.coreboot.org/__<u></u>mailman/listinfo/coreboot</a><br>
<<a href="http://www.coreboot.org/mailman/listinfo/coreboot" target="_blank">http://www.coreboot.org/<u></u>mailman/listinfo/coreboot</a>><br>
<br>
<br>
<br>
<br>
</blockquote>
</blockquote></div><br></div>