On 03/01/13 23:23, gary sheppard wrote:
Numerous security experts have already said it is anything but secure, and it will never be secure. They have only said this quietly, and that "voice" has been minimalized, while "PROGRESS" is shouted to the heavens. Hey, look at android and how phone makers "lock" it down. Does it stay locked? No! Come on people, put your heads out of... ;)
Gary
Security is not an absolute. It is a tradeoff against the time needed to overcome it. Secure Boot is more secure than no security. coreboot offers no security. coreboot can never be "the Solution to the Secure Boot Fiasco" until it can offer better security than Secure Boot.
Yes there may be breaks for early implementations of Secure Boot but anyone predicting that it can never be fixed is a very brave person. Never is a long time. Remember, fixed does not mean perfect. Fixed just means takes longer to overcome than anyone cares to invest in it.
Sorry but "this will be broken because everything before it has been broken" is not a credible critique; that is the inductive fallacy.
Andrew
Actually, there is an open source secure boot being sold now that allows people the option of bypassing it, and booting anything they want. These systems are based on U-boot and coreboot.
Andrew, so far, I don't find your arguments very convincing.
ron
You are correct, "never" is far too long to quantify. I stand corrected.
Secure by default because --Big Brother says that it is secure" is tantamount to loss of individuality and personal freedom.--
Perhaps -- Secure by means of openly auditable and verifiable security trace would be better?--
"Big Brother" is not always an answer.
On Fri, Jan 4, 2013 at 4:03 PM, Andrew Goodbody ajg4tadpole@gmail.comwrote:
On 03/01/13 23:23, gary sheppard wrote:
Numerous security experts have already said it is anything but secure, and it will never be secure. They have only said this quietly, and that "voice" has been minimalized, while "PROGRESS" is shouted to the heavens. Hey, look at android and how phone makers "lock" it down. Does it stay locked? No! Come on people, put your heads out of... ;)
Gary
Security is not an absolute. It is a tradeoff against the time needed to overcome it. Secure Boot is more secure than no security. coreboot offers no security. coreboot can never be "the Solution to the Secure Boot Fiasco" until it can offer better security than Secure Boot.
Yes there may be breaks for early implementations of Secure Boot but anyone predicting that it can never be fixed is a very brave person. Never is a long time. Remember, fixed does not mean perfect. Fixed just means takes longer to overcome than anyone cares to invest in it.
Sorry but "this will be broken because everything before it has been broken" is not a credible critique; that is the inductive fallacy.
Andrew
Am 2013-01-05 01:03, schrieb Andrew Goodbody:
coreboot can never be "the Solution to the Secure Boot Fiasco" until it can offer better security than Secure Boot.
We do. Same level of verifiable boot (by doing signature checks on loaded code) without the UEFI complexity.
Microsoft made Phoenix implement ASLR and NX bit support to lock down the firmware some more (see UEFI plugfest slides of 2011/2012). That's complexity just to manage existing complexity.
And now AMI dreams of an UEFI OpenGL library (also plugfest slides).
coreboot has neither: No ASLR, but we don't run any custom code before jumping into the signed kernel, which can't do callbacks. No need for NX bit support for the same reason. No loadable modules that require signature checks. No resident API for operating systems (and no attack surface that results from this). And no plans for an OpenGL library - since with coreboot, firmware is long gone when OpenGL becomes interesting. (though someone could arguably push Linux + initrd with libGL.so into flash as a payload)
From an execution stand point, our secure boot approaches are quite similar: signed binaries with (RSA) signature checks. The issues over time were similar (my prototype for such functionality in 2008 had TOCTOU issues, they solved similar problems in 2011). Just the signature formats vary.
But we aim for simplicity, which is a quality of its own - especially when it comes to security.
In fact, even the "Freedom" issues are similar: Google voluntarily did the right thing and added a user override button (hardware) to their chrome devices. Without that, coreboot in those systems wouldn't help a bit, since they'd be just as locked down as a UEFI secure boot device without custom key enrollment.
The issue with UEFI Secure Boot is the motivation of the guardian of standard and implementation. It's not Intel, it's Microsoft: They worked with (and/or paid) Insyde to do the secure boot implementation. They worked with (and/or paid) Phoenix for the ASLR/NX lock down. And they add a bunch of requirements for hardware implementors that exceed the UEFI spec by way of their Windows Logo initiative.
It definitely matters right now for PC platforms where the Win8 Logo requirements only changed to the current state (so that they _require_ a key enrollment option for the user, and a way to disable secure boot) after public pressure. PC is a market they control, so vendors can't ignore the Win Logo stuff.
Patrick
On 05/01/13 08:26, Patrick Georgi wrote:
Am 2013-01-05 01:03, schrieb Andrew Goodbody:
coreboot can never be "the Solution to the Secure Boot Fiasco" until it can offer better security than Secure Boot.
We do. Same level of verifiable boot (by doing signature checks on loaded code) without the UEFI complexity.
Ahh, sorry I missed that detail didn't I? That's really good to know.
In fact, even the "Freedom" issues are similar: Google voluntarily did the right thing and added a user override button (hardware) to their chrome devices. Without that, coreboot in those systems wouldn't help a bit, since they'd be just as locked down as a UEFI secure boot device without custom key enrollment.
And here is the crux of the issue. Distribution and management of keys is a major problem be it coreboot or Secure Boot.
The issue with UEFI Secure Boot is the motivation of the guardian of standard and implementation. It's not Intel, it's Microsoft: They worked with (and/or paid) Insyde to do the secure boot implementation. They worked with (and/or paid) Phoenix for the ASLR/NX lock down. And they add a bunch of requirements for hardware implementors that exceed the UEFI spec by way of their Windows Logo initiative.
It definitely matters right now for PC platforms where the Win8 Logo requirements only changed to the current state (so that they _require_ a key enrollment option for the user, and a way to disable secure boot) after public pressure. PC is a market they control, so vendors can't ignore the Win Logo stuff.
Patrick
Agree 100%. I do not understand why people are lumping Intel in with Microsoft on this one. 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.
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.
Andrew
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
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.
Gary
On Sat, Jan 5, 2013 at 6:52 AM, Patrick Georgi patrick@georgi-clan.dewrote:
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 http://www.coreboot.org/**mailman/listinfo/coreboothttp://www.coreboot.org/mailman/listinfo/coreboot
-
Andrew Goodbody -
gary sheppard -
Patrick Georgi -
ron minnich