On Wed, Apr 6, 2022 at 12:23 PM Justin Forbes <jmforbes@xxxxxxxxxxx> wrote: > > On Tue, Apr 5, 2022 at 6:39 PM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > > > On Tue, Apr 5, 2022 at 3:08 PM Jared Dominguez <jaredz@xxxxxxxxxx> 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? > I want a secondary key that we can use that's trusted only by the kernel so that it's easy to revoke/rotate without forcing the whole mess on everyone. Having a keyring in the kernel that allows the kernel to trust certificates without having to import them into firmware drastically reduces the damage and improves the security of the system by making it easier to manage trust in the first place. The whole reason we sign shim with the Microsoft certificate and then have shim trust our certificate for grub and the kernel is because we recognize that making people fiddle with the firmware is a horribly bad idea. That hasn't changed in 20 years. Shim changes very little, and everything that uses the Fedora cert can change often without involving the whole mess. I want that principle extended to kernel modules too. -- 真実はいつも一つ！/ 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 on the list, report it: https://pagure.io/fedora-infrastructure
