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.
Conversation
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
source.android.com/security/verif is the model that we're used to using. The OEM flashes eFuses with their signing keys for firmware and builds their OS signing key into the last stage. They can then choose if they want to support flashing a custom key to a secure element when unlocked.
1
This discussion has nothing to do with Android or ARM though.
1
Why not? ChromeOS or Android on x86 has verified boot and doesn't involve Microsoft in any way. An x86 Android device can use UEFI and it doesn't involve Microsoft's take on Secure Boot.
1
Because Microsoft signed a shim loader for Linux. That was the entire point in the initial post. Microsoft is playing nicely with one and only one F/OSS ecosystem and saying "F-U" to everyone else.
1
I'm well aware of that. GPLv3 forbids that kind of setup. Projects using GPLv3 should probably be aware of what the highly restrictive license they're using requires.
1
GPLv3 projects are not the only issue. You're fixated on just that one topic for some reason.
1
That's what it says in the linked image. It's portrayed as if Microsoft did something wrong by rejecting GPLv3 code but if they had signed GPLv3 code for this it would be violating the GPLv3. Their process SHOULD forbid GPLv3 in order to comply with the licensing terms.
1
There was a thread, more than just an image... so yeah, you're hyper-fixated on just that image... and not the rest of the content I provided apparently.
1
I'm not "hyper-fixated" on the image. I did read your thread before replying.