> On Thu, Dec 22, 2022 at 12:00 PM Luca Boccassi <bluca(a)debian.org> 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
