Neal Gompa wrote: > 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. Sorry, there is a misunderstanding there. I did not intend to blame Microsoft for the restrictions within the kernel Linux imposed by the security model. There are 2 separate issues here: 1. Any operating system (in practice, the initial bootloader, shim in our case, but that is shipped by the operating system) must be signed by Microsoft to boot at all. AND 2. The security model prevents basic Linux kernel functionality. Both are ultimately failures of the UEFI spec and not of Microsoft. Microsoft is not a party to issue 2 at all. > 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. The thing is, the engineers claim that this LOCKDOWN "feature" is necessary to comply with the Secure Boot spec. I know some other distributions have a different interpretation, which makes this security entirely moot, because if the non-locked-down kernels break the security model, it is enough to have one distribution offering a signature path to such a kernel and the security model is already broken. But despite that, Red Hat does not want to take the risk of being held responsible for breaking the security model. > 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. I don't know what they do differently. All I know is that it is not allowed by the Fedora kernel under Secure Boot restrictions. There are also other, more subtle restrictions, such as banning even root from accessing kernel memory. > 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? It is actually an ASUS P8Z68-V motherboard, introduced in 2011. It is labeled as "Windows 7 ready". According to: https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#Secure_boot_criticism the Secure Boot requirement was introduced with the Windows 8 certification in 2011, which my motherboard predates. Kevin Kofler _______________________________________________ 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
