![[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.
Coreboot = dead soon?
(Anonymous) 2012-06-06 06:01 pm (UTC)(link)Such a shame. I much preferred Coreboot's minimalism. But even openfirmware would have been preferable over UEFI. I still don't understand the raison d'etre of (U)EFI, and it seems to have been overloaded with boatloads of "stuff" of dubious necessity.
From what I understand, even an open source "UEFI-light" is not in the cards, right? Man, this really is turning into a nightmare.
Re: Coreboot = dead soon? How is firmware flashing prevented?
How is this done? Does the boot firmware send some kind of signal to the flash chip to lock itself until the next reboot?
It would be better if operating systems (such as Windows and Fedora) were responsible for deciding that it is lockout time on the flash chip. This would allow a user supplied operating system booted to decide what should be done.
I'm hoping you'll reply and say I've got it wrong -- that we'll be in a world where you can't flash an arbitrary firmware when running a Secure Boot version of Windows or Fedora, that those systems will be the ones checking signatures before allowing flashing. Thus the freedom to switch to coreboot will still there for those who boot a different operating system.
Underlying assumption here: that the signature checking on new firmware is being done by either the boot firmware itself (with lockout to follow) or by operating systems (in which case we can run an operating system that doesn't do so) -- there's no weird crypto hardware like TPM being tied up in the Windows 8 certification requirements.
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?
Re: Coreboot = dead soon? How is firmware flashing prevented?