On Tue, Dec 20, 2022 at 9:10 PM Kevin Kofler via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > Daniel P. Berrangé wrote: > > That is not correct. There are a number of benefits of UKIs. > > > > The most critical is that the initrd content and cmdline is > > covered by the SecureBoot signature. > > From an end user point of view, having more stuff covered by Restricted Boot > is not a benefit. > I do believe Secure Boot can provide value, but we need to consider it only as "bootstrap security" rather than "boot security". On its face, it's pretty absurd to restrict operating system content to pre-boot signatures. The original goal of secure boot support in Linux was to support the de minimis effort to enable Free platforms to work on PCs where it may not be easy or possible to turn off Secure Boot. There was a very real fear that it would be a reality, which is why we sign our boot code with the Microsoft certificate. But our design deliberately uses the Microsoft certificate to chain into our own. Where we fell apart compared to Windows and macOS is that we decided that we wanted to have all kernel code locked down exclusively by either firmware certificates or hardcoded certificates in shim. In retrospect, this was a bad move because it crippled our ability to enable driver integrity protection for the operating system using similar techniques used by other operating systems. On the flip side, because our own ability to enable and support operating system trust was hamstrung by firmware certificates, we did finally get NVIDIA to open up[1]. Was it the right decision anyway? I don't think so. The way the UAPI group envisions system security clearly shows where this falls apart: we increasingly rely on parts of the system that we have no influence on to guide our system integrity protection. Secure Boot would have been great if it was designed as a user-friendly way to establish and control system content trust. But that's not how it works in practice at all. And the sheer amount of resistance around making it work that way demonstrates how much of a failure it is for that purpose. And it bears repeating: Windows doesn't use Secure Boot for system integrity protection. It has its own in-OS mechanisms instead. As someone whose day job involves working with teams who develop both Windows and Linux drivers (and in the past, even macOS drivers!), I can categorically say that Windows driver engineering processes are way friendlier than Linux ones, precisely because Windows drivers are deliberately not exposed to Secure Boot *at all*. Running development versions of drivers just requires installing a development certificate into the NT kernel certificate store. The equivalent process for Linux is to load a custom secure boot certificate into firmware, which is fraught with peril and potentially not even possible. I cannot tell you how many times I've bricked a system by attempting to load another cert only to find out there's not enough space and the firmware didn't handle that well. We've failed here, badly. And nobody cares. [1]: https://developer.nvidia.com/blog/nvidia-releases-open-source-gpu-kernel-modules/ -- 真実はいつも一つ！/ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
