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
That's what the README screenshot in the original post is about. It says they're refusing to sign GPLv3 code. They would be participating in violating the license if they did that.
github.com/rhboot/shim/bl is not GPLv3 and the Linux kernel is not GPLv3.
2