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.
Conversation
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.
1
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
Only the motherboard vendors could decide that they won't produce motherboards with support for custom secure boot keys. Microsoft probably should stop signing those shims. The proper way to use secure boot with Linux is using a key for that Linux distribution, not Microsoft's.
1
Traditional Linux distributions aren't actually providing a real implementation of secure boot anyway. It stops at the bootloader or kernel.
Microsoft shouldn't do this at all and when people install other OSes they should add the Linux distribution's key to UEFI keychain.
Motherboard vendors should support custom keys, and I think most motherboards purchased as a retail product do support this. I don't understand why anyone would want to use a shim signed by Microsoft, or what the point is of this if only a bootloader and the kernel are verified.