Florian Weimer wrote: > But they also say this: > > | The default state of Secure Boot has a wide circle of trust which can > | result in customers trusting boot components they may not need. Since > | the Microsoft 3rd Party UEFI CA certificate signs the bootloaders for > | all Linux distributions, trusting the Microsoft 3rd Party UEFI CA > | signature in the UEFI database increase[]s the attack surface of > | systems. A customer who intended to only trust and boot a single Linux > | distribution will trust all distributions–much more than their desired > | configuration. > > And this is an accurate description of the situation. > > Unfortunately, Fedora promoted this broken model with pervasive > cross-distribution/cross-OS trust as well.
And what is the alternative? The whole model of allowing to boot only a whitelist of operating systems is inherently a vendor lock-in and hence inherently broken. Restricting the list to one or two (Microsoft and [distro of choice]) vendors out of the box is totally anticompetitive and a freedom killer. > People are generally quick to criticize those who control a PKI, but very > few organizations are willing to step up to hold the key material for the > key of last resort because of the risk inherent to that. Consequently, > pretty much all distributions hide behind the Microsoft key, instead of > running their own PKI and working with OEMs to get it accepted by the > firmware. Nonsense. OEMs have made it pretty clear from day one that they will not trust any other company than Microsoft out of the box. That, and nothing else, is why everyone is forced to rely on Microsoft's key. Microsoft's third-party key was from the beginning an alibi action to avoid monopoly lawsuits and boycotts. (I guess the processing fee of, IIRC, $100, was not the main motivator, they would probably charge more if that were the case. So that fee only stands as a barrier to exclude smaller GNU/Linux distributions.) They would not have been able to pull off Restricted Boot with so little upcry without that alibi key. I can only assume that they were, from day one, only waiting for a good excuse to pull the plug on that key, and it seems that the excuse has now been found. If they were serious about equal access to hardware for all manufacturers, they would have used the SAME signing-key as for their own operating systems. > I wonder if this Secure Boot interoperability failure is the result of > using PKI in a situation where it is really not applicable. Well, indeed, PKI is not applicable to the boot process at all, because the whole idea of not booting all operating systems out of the box is anticompetitive, anti-freedom, and flawed. > Maybe the answer to that this issue is to have a minimal > (cross-distribution) boot loader that displays the SHA-256 hash of > second-stage boot loaders (requiring physical presence before booting), > and offer to to enrol their hashes for future automated boots (similar > to SSH's leap-of-faith authentication). Requiring users to jump through even more hoops to boot their operating system of choice is not going to be acceptable to anybody. The only answer I see is that Restricted Boot needs to go away. But that is why Microsoft is now abusing full-disk encryption to make it impossible to disable Restricted Boot without destroying all your data. (Chainloading is not the only way to change the TPM measurements and hence break the TPM sealing, disabling Restricted Boot will also do it.) It makes me particularly sad when I see GNU/Linux developers touting the purported security merits of Restricted Boot and TPM Treacherous Computing in their blogs. Kevin Kofler _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure