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 <[email protected]> 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 <[email protected] >> <mailto:[email protected]**>> 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: [email protected] <mailto: >> [email protected]> >> >> 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> >> > >> >> >> >> >>
-- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
