"Why not just use Coreboot?"

[mjg59]

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.

Comments

firmware/hardware-level password protection as an alternative

[(Anonymous)]

Hello Matt. I was wondering: why not lock down ROM flashing ability, by requiring a password stored in firmware? This check would have to be implemented on the hardware or firmware level.

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

[(Anonymous)]

One thing I forgot to point out is that the password option puts users in control over their own machines, while still offering security against malware.

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

[mjg59]

Yes, you could do that. But every machine would be shipped with Microsoft's signature installed, and Linux could only be installed if you were willing to type in a machine-specific password printed on a piece of paper you probably lost when you unpacked the machine. The problem here isn't coming up with technical solutions, it's coming up with technical solutions that the vendors would be willing to ship and which don't cause a different set of problems.

Re: firmware/hardware-level password protection as an alternative

[(Anonymous)]

Or probably better just a flip switch/jumper on the board (flashable/unflashable mode) - this is something manufacturers would go for.
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.