The Linux kernel isn't in question here at all though. It's the loaders that are in question.
Conversation
Linux kernel is capable of acting as an EFI application and can be booted directly. The use case for a shim is just that you have to deal with this additional party unlike a typical secure boot implement where the vendor making the OS controls the key such as with Android phones.
1
As long as the shim is GPLv2 or more permissively licensed, this isn't an issue with those either. This is a deliberate restriction in GPLv3 working as intended.
I think Microsoft legitimately cannot sign and distribute GPLv3 code as part of this. The reasoning seems correct.
1
1
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.
1
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.
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
Show replies