![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
"Why not just use Coreboot?"
Why not just avoid the entire Secure Boot problem by using Coreboot? Because the reason we have the Secure Boot problem is because Microsoft's Windows 8 certification requirements mean vendors have to ship a UEFI implementation with Secure Boot. You could satisfy that by using Coreboot with a Tiano payload, but it'll still have Secure Boot enabled so you still have the same set of problems. But maybe you could just reflash your system with Coreboot? No, because another part of the requirements states that all firmware updates have to be cryptographically signed now. The only way to reflash will be to attach a flash programmer directly to your motherboard.
So why not just use Coreboot? Because it doesn't help solve this problem in any way.
So why not just use Coreboot? Because it doesn't help solve this problem in any way.
Re: Coreboot = dead soon? How is firmware flashing prevented?
It looks like firmware is locked out from write at a certain point by the boot firmware. Firmware updates that are initiated from the operating system are actually just queued up for installation by the current firmware on the next boot, and as such the current firmware does the final cryptographic checks before overwrite.
The UEFI specs provide some considerable APIs/protocols for changing stored keys and hashes but execution of these has to be done in "setup mode". It's not clear if UEFI firmwares have to provide any guis for actually using those APIs -- so its all going to be vendor by vendor.
Anyone know what the Microsoft Windows 8 certification requires? Are they just asking for users to be able to turn off secure boot for other operating systems but without requiring that the GUIs allow the firmware to be reflashed and or the keys/hashes changed?
For reference, this is one of the simple things I was looking at other than the UEFI spec itself
http://www.uefi.org/learning_center/UEFI_Plugfest_2012Q1_v3_AMI.pdf
and it notably referrenced this:
http://csrc.nist.gov/publications/nistpubs/800-147/NIST-SP800-147-April2011.pdf
"""
Security guidelines are specified for four system BIOS features:
• The authenticated BIOS update mechanism, where digital signatures prevent the installation of
BIOS update images that are not authentic.
• An optional secure local update mechanism, where physical presence authorizes installation of
BIOS update images.
• Integrity protection features, to prevent unintended or malicious modification of the BIOS outside
the authenticated BIOS update process.
• Non-bypassability features, to ensure that there are no mechanisms that allow the system processor or any other system component to bypass the authenticated update mechanism.
"""
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.
Re: Coreboot = dead soon?