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
