"Why not just use Coreboot?"
Jun. 6th, 2012 10:32 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59Why 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.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2012-06-06 04:10 pm (UTC)UEFI is so complex that it is almost impossible to implement bug free.
no subject
Date: 2012-06-06 04:16 pm (UTC)What keys can be used to sign the firmware (typically)?
Date: 2012-06-06 05:38 pm (UTC)Re: What keys can be used to sign the firmware (typically)?
Date: 2012-06-06 05:40 pm (UTC)Coreboot = dead soon?
Date: 2012-06-06 06:01 pm (UTC)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?
Date: 2012-06-12 05:46 pm (UTC)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?
Date: 2012-06-12 08:26 pm (UTC)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?
Date: 2012-06-12 10:01 pm (UTC)"""
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?
Date: 2012-06-12 10:05 pm (UTC)Re: Coreboot = dead soon? How is firmware flashing prevented?
Date: 2012-06-12 09:37 pm (UTC)no subject
Date: 2012-06-06 06:07 pm (UTC)firmware/hardware-level password protection as an alternative
Date: 2012-06-06 09:00 pm (UTC)I wouldn't be surprised if this is not possible on today's systems, but wouldn't this be an appealing alternative to placing the burden of security on some other key-signing authority? The computer would come with a pre-set random password, and/or ask for one on first boot. Ideally, users could be given the option of using the password, or using Microsoft keys.
I'm curious if you can spot any problems with this idea. One that I see is that the password check may need to be at the cpu, chipset, or firmware level before giving write access to firmware. That might be tricky to implement and/or depend on AMD/Intel wanting to implement it.
Another catch is: if flashing is done within a booted OS, then you face the problem of keyloggers. But this can be avoided by booting from a usb stick to flash the firmware.
I think having this choice is preferable to a "Trust Microsoft's key signing authority and the ability for every signed GNU/Linux distro to lock down their bootloaders, kernels and modules appropriately" approach as the only option besides having no protection at all.
What do you think about this idea?
Re: firmware/hardware-level password protection as an alternative
Date: 2012-06-06 09:10 pm (UTC)With key signing, you have to trust the keysigner, the intentions of those who compile the signed operating system, and the meticulousness of those compiling the operating system, hoping they disable every vulnerability. And in the end, there's less freedom for the user, when you depend on other people's keys.
Re: firmware/hardware-level password protection as an alternative
Date: 2012-06-06 09:17 pm (UTC)Re: firmware/hardware-level password protection as an alternative
Date: 2012-06-07 02:29 pm (UTC)I really do not see a problem with this. If at the end of the day you can flash the bios directly, then there is no point to thinking of it in a physical security sense. If someone has access to the system it is insecure. Therefore, you could also just write the firmware password on the motherboard or on a sticker on the PC, and then have the user change it at their will.
I believe that we should be completely discounting Linux on SecureBoot, this is 2012, we should not be thinking of it as a "hack your system and install linux" or a follow the rules set out by verisign (who are as bad as Microsoft btw) and Microsoft. This is like buying an iPhone with the intention to run Android.... You intend to use Linux from the offset, so getting manufacturers to realize we won't buy anything we don't own if the best policy.
If you are thinking in the mentality of a user being able to download Linux take it to their local library and boot into Linux instead of Windows - this is never going to happen. Or if you are thinking there are users who are incapable of disabling SecureBoot who will be capable to know how to boot it on their system, they do not exist. These users will most likely be using iPads or in the future windows on arm. Companies using Linux will be able to create their own sets of keys/disable secure boot.
You need to forget about this and start concentrating on people buying free software/open computers with Linux pre-installed.
I for one will be moving away from using Fedora if it starts to support this structure of hierarchical forced trust. This would include even a Fedora or free software signing key.
EFI is horrible, just see how much so.
Date: 2012-06-06 10:07 pm (UTC)http://www.youtube.com/watch?v=V2aq5M3Q76U
Re: EFI is horrible, just see how much so.
Date: 2012-06-07 12:42 am (UTC)Re: EFI is horrible, just see how much so.
Date: 2012-06-07 05:03 pm (UTC)So, please get us standalone slides, a paper, a blogposting, whatever instead. A medium allowing us to peruse the content at our own speed and by plain text.
(Not even *trying* OpenID this time…)
Google will disagree with you for now
Date: 2012-06-06 10:19 pm (UTC)Realistically, though, if we ever get to the point that we can't do something like coreboot on hardware, the next target is Linux -- as it has been all along, since this secure boot nonsense first started to appear. And we can't hide behind the ARM: MS is pushing UEFI on that one too.
The Chromebook/Chromebox have a verified boot that's open source right down to the BIOS. That's how it ought to be.
Not that I speak for Google.
Re: Google will disagree with you for now
Date: 2012-06-07 12:43 am (UTC)Doing a firmware port can be quite messy, and it requires intimate knowledge of the chipset AND board, including schematics, etc. Sure, it can be reverse engineered from whatever is already there, but in general it would be a 100% reactive project, always having to scramble and fixup things when the vendor does a small hardware modification, etc. Not exactly something that end users can rely on.
Keep in mind that the BIOS is where _all_ the PC manufacturers hide the abstractions to all the crazy stuff they do on hardware, including all the bug workarounds. They can change hardware in the middle of a production run because they can coordinate a firmware that goes on those specific machines, etc. So it'll be a constant churn trying to deal with all of that.
Re: Google will disagree with you for now
Date: 2012-06-07 12:44 am (UTC)Re: Google will disagree with you for now
Date: 2012-06-07 10:45 am (UTC)For me, this probably means I'll only buy coreboot-supported motherboards from now on, and will return them to the store if flashing the firmware fails.
Re: Google will disagree with you for now
Date: 2014-02-18 07:34 pm (UTC)Small correction
Date: 2012-06-06 11:13 pm (UTC)Re: Small correction
Date: 2012-06-07 12:35 am (UTC)Why hasn't Red Hat gone to the DOJ?
Date: 2012-06-06 11:29 pm (UTC)Why haven't Red Hat and the other Linux friendly tech companies gone to the DOJ about this? This is clearly setting Microsoft up to be the gatekeeper whether or not they are being benevolent about it at the moment. It is simply unacceptable that a company with a monopoly hold on the OS market should be the sole driving force behind this technology. Especially considering past threats against Linux. Why isn't anyone screaming bloody murder right now?
Re: Why hasn't Red Hat gone to the DOJ?
Date: 2012-06-07 08:36 am (UTC)Oh man they *DID* scream bloody murder by everyone involved trusted what Microsoft said about not preventing anyone to have more than one key or disabling secure boot.
Of course the latter does not solve the problem, the former does mean "not preventing" is going to be "going out of one's way to make sure nobody is widely including another key".
Re: Why hasn't Red Hat gone to the DOJ?
Date: 2012-06-07 08:53 am (UTC)Re: Why hasn't Red Hat gone to the DOJ?
Date: 2012-06-07 03:45 pm (UTC)Seriously?
Date: 2012-06-07 01:45 pm (UTC)Why not just drop ALL of those wasted words and start with "Microsoft's Windows 8 certification requirements means..."
Flame
Date: 2012-06-07 03:32 pm (UTC)there is a www.change.org petition started about UEFI
Date: 2012-06-07 04:33 pm (UTC)https://www.change.org/petitions/federal-trade-commission-stop-microsoft-pc-makers-monopoly-plan-for-uefi-boot-loader-restriction
People are stupid as usual
Date: 2012-06-08 05:03 pm (UTC)Re: People are stupid as usual
Date: 2012-06-08 05:13 pm (UTC)Re: People are stupid as usual
Date: 2012-06-08 11:14 pm (UTC)Re: People are stupid as usual
Date: 2012-06-08 11:18 pm (UTC)Re: People are stupid as usual
Date: 2012-06-08 11:19 pm (UTC)delete the duplicate please
Date: 2012-06-08 05:08 pm (UTC)Someone can just write and sign the bytecoode interpreter. Then what? Even though the
interpreter itself is not malicious it could be used for malicious purposes. Where do
you draw a line? Will you ban thin hypervisors because some flaw could allow unsigned
VM code to change something on the host?
>>People desperately want to believe that the Secure Boot implementation is fundamentally
>>broken, and that's just not true.
But it is true.
Certificate Authority system is broken. Adding a 3rd party to a chain of trust reduces
security by increasing the number of entities you implicitly trust. The whole CA thing
is just a money raking scheme, a big boys club membership pass.
>>For starters, you'll need to provide some form of plausible ID for Verisign to
>>authenticate you and hand over access.
Yes, as if someone from Russia or China couldn't do that. Good luck trying to arrest them.
Anyway, Verisign wouldn't be the first security company that got compromised.
Verisign has been tricked into issuing certificates in Microsoft's name:
http://news.cnet.com/2100-1001-254628.html
Diginotar has been breached:
http://isc.sans.edu/diary.html?storyid=11500
RSA has been breached:
http://www.nytimes.com/2011/06/08/business/08security.html?pagewanted=all
Microsoft's own certificates were compromised few days ago and had to be revoked, not
to mention that they have allowed Flame malware to exist and do its bidding. It's almost
as if that was a deliberate backdoor waiting to be exploited:
http://blogs.technet.com/b/msrc/archive/2012/06/03/microsoft-releases-security-advisory-2718704.aspx
And what if someone with enough determination actually physically breached into Verisign
and got the UEFI root CA thus compromising everything? How is that going to be revoked?
Will it require user consent, or will it be silent, mandatory key update? What will happen
with user added keys? Will you trust the state of potentially compromised system or you
will zap the key store and just load the new key? Will you have to pay again to sign with
a new key?
The whole point of secure boot is not to secure our computers from malicious software
(did anyone seriously believed that for one second?), but to secure software and media
content that we "the pirates" might try to "steal".
Next thing you won't be able to pass the BIOS boot screen unless the computer is online
and can check for updated or revoked certificates. From that point onwards it is just a
matter of months before they will silently start scanning your data and sending it to
them through the out-of-band network channel.
UEFI key management application
Date: 2012-06-09 10:10 am (UTC)Let's assume, that users want to insure that their boot sequence has been verified and signed by the trusted vendor of their choice, yet still keep themselves in control to override the upstream signatures. How should that be set up?
There could be some centrally maintained list of 'root' keys that each hardware vendor imports as the default list. The signing format must be updated to allow multiple signatures on binaries. That way, the user can choose which vendor keys to trust and distributions can decide to have there code signed by multiple vendors who choose to take responsibility for the security of the code. The UEFI implementation must provide a simple application to manage those keys. This simple applications must provide a consistent user experience over all UEFI implementations. It would probably be best to provide this simple application in the reference implementation. The management must allow the user to trust and distrust keys, to remove keys and to add keys from external media and to prioritize keys in a list to resolve potential conflicts of binaries whose signatures have been revoked by some vendors but not by others. There should probably also be an easy way to restore the default list. Yet there must be another application for the operating systems for every day users to generate there own key and install it on external media to add it to the UEFI key management, so that they can position their own key on top and override the vendor keys. It should also be trivial for the user to sign boot loaders, kernels, drivers they trust.
The major distributions could use a single organization like the Linux Foundation to manage a root key in the default list. Yet it would allow other distributions to distribute their own root key independently via their websites. The user would store them on external media to install them via the UEFI key management. This should allow the user to control the system while using secure boot to keep whatever integrity secure boot offers.
Re: UEFI key management application
Date: 2012-06-11 06:11 pm (UTC)Re: UEFI key management application
Date: 2012-06-11 10:34 pm (UTC)Why not just use coreboot?
Date: 2012-06-15 09:14 pm (UTC)Re: Why not just use coreboot?
Date: 2012-06-16 02:11 am (UTC)Re: Why not just use coreboot?
Date: 2012-06-16 04:11 am (UTC)Obviously not everybody would be soldering their boards left and right to replace the chips but perhaps some progress? At least the deep inter-workings of Secure Boot would be figured out (if this could be done.)