On Mon, Feb 8, 2021 at 9:13 PM Kevin Kofler via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > Chris Murphy wrote: > > If you want to take the risk of acquiring a rootkit that can > > permanently take control of your firmware, that is up to you. It > > should not be a distribution recommendation to subject users to such > > bad advice. > > And the "good advice" would be to accept that your computer will only run > operating systems approved by Microsoft and to accept a security model that > prevents basic functionality such as hibernation, third-party kernel > modules, etc.? > Don't blame Microsoft for our failings. The fact that we can't do hibernation or offer an easy path for third-party kernel modules to function in a Secure Boot environment is *entirely* our fault. After shim->grub2, Microsoft's trust ends and ours begins. We use *our* certificate from GRUB onward. The fact that hibernation is broken in Secure Boot is entirely the fault of the engineers that were in charge of developing the Fedora kernel and bootloader security mechanism, because they created the patch set that made it functionally impossible to make it work. That is, it's the LOCKDOWN feature layered on Secure Boot, not Secure Boot itself. It's obvious Secure Boot itself is no impediment to hibernation, since both Windows and macOS (both users of Secure Boot) can do hibernation just fine. The fact that third-party kernel modules are nearly impossible to set up in Secure Boot is entirely the fault of engineers who designed the certificate trust mechanism to not offer a path for semi-interactive or non-interactive trust scenarios like we have for package and repository signatures. It is theoretically possible for third-party stuff to work in a Secure Boot environment, but the path to get there is so onerous because nobody who makes this stuff for Linux cares to make this easy to work with. The trust mechanisms for Secure Boot are not fundamentally any different from how trust works for GPG (they're both rooted in PKI architectures). The difference is that expanding trust at the Linux kernel level is deliberately under-documented and considered unsupported. Additionally, creating signed kernel module packages has been broken since the beginning, since nobody cared to actually *fix* the kernel module packaging system to account for it. I've been trying to untangle this mess for months because I'm frustrated by how stupid the situation is and how we've never *tried* to make having a secure system easier. None of this had to be this way. It is so by our own inaction, not by the action of Microsoft. > And for the record, my computer's UEFI firmware is so old that "Secure Boot" > cannot even be enabled at all, even if I wanted to. > Meh. That means your computer was made before Microsoft started having vendors require UEFI firmware to include their keys for Windows certification (which was in 2006/2007). I'm surprised it still works. More power to you, I guess? -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
