[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-devel-list
Subject:    Re: future of dual booting Windows and Fedora, redux
From:       Kevin Kofler via devel <devel () lists ! fedoraproject ! org>
Date:       2022-07-30 16:20:03
Message-ID: tc3lnk$d12$1 () ciao ! gmane ! io
[Download RAW message or body]

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-leave@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

[prev in list] [next in list] [prev in thread] [next in thread]