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@georgi-clan.de mailto:patrick@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@coreboot.org <mailto:coreboot@coreboot.org> http://www.coreboot.org/__mailman/listinfo/coreboot <http://www.coreboot.org/mailman/listinfo/coreboot>
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@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@georgi-clan.de mailto:patrick@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 toknow.
It's not as obvious, since that's a payload feature, not corebootitself.
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 overcontrol over devices to their customers (who _bought_ the devices) like they used to.
Key management is a minor technical detail - chrome devices have theproper 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 inwith Microsoft on this one.
Probably because UEFI is considered Intel's brainchild, even thoughit'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 byparanoia and FUD then changes can actually be made.
The other reason for allowing secure boot to be disabled is Windows
- 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'spossible 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 tolook 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 releasedthe 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 (withintheir 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'sin 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 topressure 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 moretechnically inclined, that what I'll aim for.
Patrick -- coreboot mailing list: coreboot@coreboot.org <mailto:coreboot@coreboot.org> http://www.coreboot.org/__**mailman/listinfo/coreboothttp://www.coreboot.org/__mailman/listinfo/coreboot <http://www.coreboot.org/**mailman/listinfo/coreboothttp://www.coreboot.org/mailman/listinfo/coreboot
-
gary sheppard -
Rudolf Marek