> On Thu, Dec 22, 2022 at 12:00 PM Luca Boccassi <bluca(a)debian.org&gt; wrote:
> 
> Your concept only works in *some* enterprise hardware where it's even
> possible to have full control without breaking something. Even in my
> server gear, I can't do that without breaking the network firmware. If
> I can't safely distrust Microsoft reliably, then it's already broken.
> 
> Firmware trust has been broken since the very beginning, and it was
> broken by design in the PC world.

"My" (not really mine, but whatever) concept works on pretty much every single 
x86 consumer device sold in the past ~12 years, in every public cloud provider, 
a gazillion arm64 use cases, and more. It's only "broken" if by that you mean 
that an entire class of very real and very much alive in the wild malware 
infections are no longer possible.
Of course if you do things like deleting the 3rd party UEFI CA on machines that 
require option roms to work without allow-listing or re-signing, then things 
break, but that has absolutely nothing to do with the "concept" - if you delete 
a trust anchor, objects trusted by it are no longer trusted in the absence of 
an alternative chain, that's pretty much expected behaviour.
Obviously things can always be improved, and we are working on that, SBAT is 
the first step in that direction. But saying that the trust chain model is 
broken is simply untrue.

> Consumer PC equipment is even worse off because of how Microsoft's
> Windows requirements influence how UEFI implementations work.

You meant to say "light years ahead" here - it is not even funny anymore how 
far behind Linux is to Windows w.r.t. security, especially in the boot process. 
We have been playing catch-up for 10 years and are nowhere near done. It is 
very fortunate for the ecosystem at large that there are people who actually 
understand the threat models pushing the industry forward, because if it was up 
to the hardware vendors computer security would still be where it was in the 
mid 90s.

But we are working on it, and making progress - in some technical concepts we 
are even ahead of them right now (eg: signed TPM policies, FIDO2 for luks, 
Windows doesn't have anything like that), but only in PoCs. Now we need the 
wide adoption, and this proposal is one timid step forward in that direction. 
The fact that in 2022 there is still no mainstream distro that has closed the 
glaring security gaping hole of writable, untrusted initrd (yes some distros 
have non-default specialized flavours for this, but it's niche) should be a 
source of embarrassment for anybody who works on OS development. It is a 
difficult problem, but by no means impossible, and it really ought to have been 
fixed at least for the generic use case by now. We need to get this sorted at 
long last.
_______________________________________________
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to