Well Secure Boot is very far from perfect. Personally I think a TOFU scheme (preloaded with OEM's own signature) would do 99% of the job, while keeping it less

Well Secure Boot is very far from perfect. Personally I think a TOFU scheme (preloaded with OEM's own signature) would do 99% of the job, while keeping it less painful for the "I just want to install Ubuntu/Arch/GrumpyLinux" crowd. The machine's boot menu should just prompt the user to trust a vendor's key (e.g. not-now/never/once/forever), before booting it for the first time. My reaction is because through all the unnecessarily complicated security measures (like SELinux, UAC, Secure Boot, etc) we've taught people to run to google for "Disable Secure $WHATEVER", which is a good indicator that the technology has failed to actually secure anything. The best security is invisible. OpenBSD gets it. There are no "how to disable pledge" blog posts, because 1. pledge(2)[0] can't be easily disabled (you'd probably need to make a custom patch for the kernel to make the syscall a no-op); 2. there is no user-visible difference to doing do, because as long as the program is doing what it's expected to do, pledge is 100% invisible. This is how e.g. Secure Boot should have worked from day one, for everyone. I know I'm kinda contradicting my earlier post here, but there's no reason to disable Secure Boot in 2022 any more, even if it failed to provide the security guarantees it promised. [0]: https://man.openbsd.org/pledge.2 https://man.openbsd.org/pledge.2