Ahh, Microsoft requirements say this: """ 17. MANDATORY. On non-ARM systems, the platform MUST implement the ability for a physically present user to select between two Secure Boot modes in firmware setup: "Custom" and "Standard". Custom Mode allows for more flexibility as specified in the following: a) It shall be possible for a physically present user to use the Custom Mode firmware setup option to modify the contents of the Secure Boot signature databases and the PK. This may be implemented by simply providing the option to clear all Secure Boot databases (PK, KEK, db, dbx) which will put the system into setup mode. b) If the user ends up deleting the PK then, upon exiting the Custom Mode firmware setup, the system will be operating in Setup Mode with SecureBoot turned off. """
On systems where the firmware allows you to set a new PK (platform key) then you're able to reflash with a firmware signed by a new self-created PK.
On systems where the firmware just provides an option to wipe the PK and be in "setup mode" I presume you can subsequently boot your own operating system and set a PK from there -- can anyone confirm that UEFI specs describe setup mode this way? It would suck if such machines locked you out from changing the PK once you booted your own code.
One a new PK is installed (by a helpful firmware or a new PK intaller) then you could install your preferred firmware as a "capsule" to be installed by the old firmware on the next boot.
So, perhaps not the death of Coreboot on Windows 8 certified non-ARM hardware (without requiring special flashing hardware)? But, flashrom (http://flashrom.org) won't be useful for the first flash step, a new tool will have to be developed to do the above steps.
I'd be interested in developing a tool for installing new PKs while in setup mode and also porting coreboot to a motherboard that only ships with PK clearing -- I'm not thrilled that only Microsoft signed systems get the benifit of Secure Boot on such boards -- I'd like to "liberate" them to make for equal treatment.
This of course implies adding a Secure Boot option to a coreboot payload -- it would be interesting to decide which payload is best to enhance along those lines. Tiano may be the way to go, but perhaps grub2 as a coreboot payload using some of the enhacements that Fedora is making to it for Secure Boot purposes.
Re: Coreboot = dead soon?
"""
17. MANDATORY. On non-ARM systems, the platform MUST implement the ability for a
physically present user to select between two Secure Boot modes in firmware setup:
"Custom" and "Standard". Custom Mode allows for more flexibility as specified in the
following:
a) It shall be possible for a physically present user to use the Custom Mode firmware setup option to
modify the contents of the Secure Boot signature databases and the PK. This may be implemented by
simply providing the option to clear all Secure Boot databases (PK, KEK, db, dbx) which will put the
system into setup mode.
b) If the user ends up deleting the PK then, upon exiting the Custom Mode firmware setup, the
system will be operating in Setup Mode with SecureBoot turned off.
"""
On systems where the firmware allows you to set a new PK (platform key) then you're able to reflash with a firmware signed by a new self-created PK.
On systems where the firmware just provides an option to wipe the PK and be in "setup mode" I presume you can subsequently boot your own operating system and set a PK from there -- can anyone confirm that UEFI specs describe setup mode this way? It would suck if such machines locked you out from changing the PK once you booted your own code.
One a new PK is installed (by a helpful firmware or a new PK intaller) then you could install your preferred firmware as a "capsule" to be installed by the old firmware on the next boot.
So, perhaps not the death of Coreboot on Windows 8 certified non-ARM hardware (without requiring special flashing hardware)? But, flashrom (http://flashrom.org) won't be useful for the first flash step, a new tool will have to be developed to do the above steps.
I'd be interested in developing a tool for installing new PKs while in setup mode and also porting coreboot to a motherboard that only ships with PK clearing -- I'm not thrilled that only Microsoft signed systems get the benifit of Secure Boot on such boards -- I'd like to "liberate" them to make for equal treatment.
This of course implies adding a Secure Boot option to a coreboot payload -- it would be interesting to decide which payload is best to enhance along those lines. Tiano may be the way to go, but perhaps grub2 as a coreboot payload using some of the enhacements that Fedora is making to it for Secure Boot purposes.