So with 11, is killing Rufus, or are they going to play nicely now? Asking for a friend.
This is a very serious question BTW.
The hard requirement of SecureBoot validated by the installer means the installer cannot be ran from Rufus flash drives.
Conversation
Linux kernel is GPLv2, not GPLv3. GPLv3 has specific clauses restricting secure boot implementations. By taking the code, signing it and distributing it Microsoft would be constrained by the GPLv3 license.
This is GPLv3 working by design. It's designed to forbid doing this.
2
1
The Linux kernel isn't in question here at all though. It's the loaders that are in question.
1
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.
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
Show replies