I didn’t ask you to throw a bunch of links naming specific exploits, or specific manufacturer flaws, but to explain why signing the boot sequence chain of responsibility is not secure.Maybe read this first
Secure Boot: this is not the protection we are looking for | Broken by Design
An article trying to prove that Secure Boot is often failing to provide any kind of meaningful protection, mostly because of the number of stuff that can go wrong.broken-by-design.fr
Few examples (plenty more to come in the future)
UEFI exploit ‘worse than BlackLotus’ pwns PCs using images
Exploits bypass most secure boot solutions from the biggest chip vendorswww.theregister.comSecure Boot is completely broken on 200+ models from 5 big device makers
Keys were labeled “DO NOT TRUST.” Nearly 500 device models use them anyway.arstechnica.comIt is broken because secure boot is just a db. No way to fix this.Secure Boot has a major security issue — hundreds of devices from Dell, Supermicro and more all affected, here's what we know
PKfail vulnerability allows threat actors to install UEFI malwarewww.techradar.com
Also, “just a db” means nothing. There are plenty of solutions based on databases that are secure.
The fact that you can point us to examples where the secure boot has failed just means that you can identify bad engineers, but doesn’t prove that the secure boot (as an industry proposal) is not secure.
That is not true. Any operating system needs to be able to validate and enforce trust when it comes to allow random code to access kernel mode. Linux, macOS, Windows and whatever is to come.Not to mention that Linux does not really need it.
The rest of the message: I stopped reading on the authority fallacy. Alluding to who someone is with the intention of avoid discussing a set of facts is not the kind of conversation I want to have. I could just spit back a video of Linus saying that secure boot is the right thing to do, but I’m not because it wouldn’t add any value to it.