On Tue, Apr 5, 2022 at 6:39 PM Chris Murphy <li...@colorremedies.com> wrote: > > On Tue, Apr 5, 2022 at 3:08 PM Jared Dominguez <jar...@redhat.com> wrote: > > > The security of UEFI systems is immeasurably better. Standardized firmware > > updates, support for modern secure TPMs, OS protection from firmware (SMM > > mitigations), HTTP(S) boot support, largely shared and open sourced > > firmware codebases that aren't a pile of assembly code, and a lot of other > > features are UEFI-only. > > When users have a suboptimal experience by default, it makes Fedora > look bad. We can't have security concerns overriding all other > concerns. But it's really pernicious to simultaneously say security is > important, but we're also not going to sign proprietary drivers. This > highly incentivizes the user to disable Secure Boot because that's so > much easier than users signing kernel modules and enrolling keys with > the firmware, and therefore makes the user *less safe*. > > > >> And the amount of resistance to improving UEFI experience for hardware > >> is amazingly awful. The workstation working group has tried to figure > >> out ways to improve the experience, only to be simultaneously stymied > >> by the UEFI firmware management tools and unwillingness by anyone > >> involved to even consider that we should make this better. > > > > > > Which tools? What specific efforts have been stymied? How is any of this > > specific to UEFI versus trying to deal with things that aren't supported by > > someone? > > Namely, Fedora signing NVIDIA's proprietary driver. > > Apple and Microsoft signing NVIDIA's proprietary driver doesn't at all > indicate Apple and Microsoft trust the driver itself. It is trusting > the providence of the blob, in order to achieve an overall safer > ecosystem for their users. > > We either want users with NVIDIA hardware to be inside the Secure Boot > fold or we don't. I want them in the fold *despite* the driver that > needs signing is proprietary. That's a better user experience across > the board, including the security messaging is made consistent. The > existing policy serves no good at all and is double talk. If we really > care about security more than ideological worry, we'd sign the driver.
At the very least, it would require that Fedora have a separate key that is trusted and not the same one used for shim/grub/kernel. We certainly aren't proposing that we use the standard Fedora keys to sign a binary blob that runs in kernel space from a company who was most recently hacked last month? Justin _______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure
