* Jean Louis: > * gameonli...@redchan.it <gameonli...@redchan.it> [2019-11-04 14:05]: >> Windows is required to disable the trusted computing locks in Most new >> laptops. Other than windows there are only a few signed operating systems >> that can be installed without disabling said locks, and they are signed by >> microsoft.
> Dr. Stallman was warning about it: https://stallman.org/intel.html The FSF has given out an award in support of Secure Boot-related work, so its approach to the matter is rather ambiguous. Secure Boot with the second Microsoft key is dead from a security perspective. I think all GNU/Linux vendors nowadays have deliberate backdoors into ring 0. This means that you can boot any operating system, pretending that Secure Boot is enabled, while in fact it is not. Furthermore, downgrade protection was never implemented for Linux, so you can boot a vulnerable kernel with a known root-to-ring-0 vulnerability, and use that to boot anything else. There was never a real effort to get a secured boot into userspace, so any security benefit to GNU/Linux would have been extremely slim anyway. Clear security goals for the Secure Boot under the Microsoft trust root have never been specified. There is the first Microsoft key, reserved to their own operating systems, which does not have these problems. As far as I know, no GNU/Linux distributions are signed by it. I have only encountered it in isolation as an option in Hyper-V. Physical x86 hardware I've seen always came with both sets of keys installed. In the end, what remains is the hassle that Secure Boot creates for many users, with very little to no benefit to anyone whatsoever. I knew this would happen and wrote extensively against Secure Boot. That became a futile exercise when the FSF started supporting it, too. Sadly, it is impossible nowadays to get rid of useless cruft if it has “Secure” in its name. To be clear here, the problem is not the Microsoft trust root. I'm pretty sure Microsoft would happily hand over the trust root to any credible organization that would be willing to manage it and absorb the risk. A lot of organizations and governments criticize central control over such keys, but very few are actually willing to manage a trust root. The same thing happened with DNSSEC.