A typical secure boot implementation doesn't work this way. There's usually simply a hard-wired key for the vendor and sometimes support for using a custom key such as with Pixel phones. You don't have to get Google to sign anything to use full secure boot with any OS on a Pixel.
Conversation
Also... unlike this incredibly weak implementation of it used on x86 UEFI desktops, typical implementations verify the entirety of firmware and the OS.
There's usually no additional bootloader between the late stage bootloader (usually UEFI now) and the kernel either.
1
Many other vendors including Qualcomm use Secure Boot to refer to secure boot implementations not tied to this system.
Qualcomm's implementation has the phone OEM controlling it and that OEM can choose to support using custom keys flashed to a secure element for the OS.
2
1
Phones aside, since that's not the issue in question here.
Why does get to control all secure boot signing for the entire x86 architecture regardless of vendor?
Yes, a vendor can load other keys, but that just fractures the ecosystem if they don't sync up.
1
1
They don't control it and people are quite confused about Secure Boot. Secure Boot does not refer specifically to Microsoft's implementation of it.
CPU vendor is core root of trust. Motherboard firmware is a secondary root of trust.
Microsoft partners with motherboard vendors.
1
Microsoft does indeed control the signing process though, it is Microsoft's keys that are loaded into motherboards, usually nobody elses at this point. So MS controls the process, either directly or indirectly.
1
Not on x86 Chrome or Android devices. I'm sure there are other x86 devices with other approaches too.
They control it for motherboards seemingly only designed to boot Windows. In my experience, they almost always support using custom keys and you have use secure boot without MS.
1
It's not generally a good or particularly useful implementation of secure boot though. Also, most Linux distributions only support verifying the kernel and then stop there which is useless and provides no actual useful security properties unlike proper secure/verified boot.
1
I think you're missing the entire point of what I was getting at here...
1
I don't think I'm missing anything. GPLv3 forbids having an immutable root of trust. It would be a violation of the GPLv3 to distribute software that only works with a specific signature. Microsoft would be distributing it by signing it and sending it back signed.
1
GPLv3 considers an immutable root of trust for secure boot to be a bad thing and forbids it. That doesn't mean people can't do it. It just means that when they do, they can't distribute GPLv3 software as part of it.
You're still hyper-fixated on GPLv3. That really isn't my issue.
2
The keys loaded into consumer retail motherboards are Microsoft's keys.
That makes Microsoft the sole arbiter of who gets to run what on these systems.
Its only a matter of time until Secure Boot is no longer optional.
Microsoft could decide to cut off ANYONE at ANY TIME
1
1
Show replies