"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

Why not just use coreboot?

[(Anonymous)]

Secure Boot resides within UEFI, like you said. UEFI resides within Flash memory. Agreed? If you attach that "flash programmer directly to your motherboard" and replace the data with Coreboot with Tiano, wouldn't you then erase the Secure Boot software and replace it? If not, what are you programming? The only way you'll be able to still have the Secure Boot data on the device after flashing, is if it's an incomplete flash, or you flashed the wrong chip..

Re: Why not just use coreboot?

[mjg59]

If you're able to reflash coreboot then you're able to reflash a modified version of your existing firmware that has secure boot disabled.

Re: Why not just use coreboot?

[(Anonymous)]

If that's the case then the chip must have restricted write access, which doesn't surprise me. Couldn't you then at least extract the ROM and flash it to a different chip? A chip that doesn't have Secure Boot enabled? Perhaps even try to reverse engineer the firmware directly and strip out the secure boot code? DRM such as SecuROM (much often used in video games) uses SSL and many other forms of cryptography, the same types you have mentioned before. People modify the .exe files at assembly level to remove the DRM from the executable. Perhaps the same thing could potentially be done for Secure Boot? Reverse-engineering such code is not an easy task at all however some (Coreboot) developers can make sense out of some of the compiled assembly instructions from the BIOS.

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.)