On Tue, Apr 5, 2022 at 4:10 PM Neal Gompa <ngomp...@gmail.com> wrote:
> On Tue, Apr 5, 2022 at 3:38 PM Adam Jackson <a...@redhat.com> wrote: > > > > On Tue, Apr 5, 2022 at 3:15 PM Neal Gompa <ngomp...@gmail.com> wrote: > > > > > We also lack solutions for dealing with the NVIDIA driver in > > > UEFI+Secure Boot case. Are you planning to actually *fix* that now? > > > Because we still don't have a way to have kernel-only keyrings for > > > secure boot certificates to avoid importing them into the firmware. > > > > Couple of thoughts, here: > > > > 1 - This is a non sequitur to the question of removing BIOS support, > > because Secure Boot is not a BIOS feature, so nobody relying on Secure > > Boot today would stand to lose anything. > > > > 2 - How is this our problem to solve? NVIDIA are the ones with the > > private source code. > > > > It's our problem because the problem isn't specific to NVIDIA, it's > specific to how people compile and load kernel modules of their own. > We should not require loading keys into firmware for user built kernel > modules. An OS-level module should be trustable at the OS kernel > level. > > Thus, it should be: MS cert -> shim -> Fedora cert -> grub -> kernel > -> user cert -> user kmod. > > > 3 - Your complaint describes solution: import NVIDIA's signing key > > into your firmware. If you want both Secure Boot and nvidia.ko so > > badly, then you as the consumer need to tell your platform to trust > > what NVIDIA signs. If that's a burden, again, see point 2 about who > > exactly is making your life hard here. Remedies there might include > > some UI streamlining around mokutil, or getting nvidia and nouveau to > > use the same (open) kernel driver so the question just goes away. > > > > This problem also makes life miserable for people working with third > party open source kernel modules too. As a live streamer, for example, > I need to use v4l2loopback, which will never exist in mainline because > v4l2 maintainers don't like it at all. > > Broad non-Mac hardware only became available after Windows 8 / Windows > Server 2012 R2. Yes, some hardware existed a few years before, but it > was not broadly available before 2013. We didn't discontinue i686 in > Fedora until Fedora Linux 31, which was over 15 years after the first > x86_64 system. The user experience with x86_64 was immeasurably better > than i686 at that point in time. > 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. > We do not have a better experience with UEFI *right now*. I know of > plenty of people intentionally choosing BIOS because the user > experience is better, even though it's older/bad technology. Because > using BIOS means kmods work. Because using BIOS means hibernate works. > Because using BIOS means they can get an equivalent experience > leveraging their hardware that they can get on Windows today with > UEFI. Maybe none of you proposing this Change use these things, but > I'm telling you these things matter. > This is really vague, especially considering that the amount of official hardware support for Linux outside the top 3 OEMs is dicey anyway. Additionally, lots of vendors are treating legacy boot as unsupported (or "supported" but only for Linux, i.e. not really tested), so the same argument could be made the other way. > 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? > I will *not* force people to deal with importing keys into firmware. > It's brittle, buggy, and often completely broken on motherboards. Many > of those UEFI implementations are extremely buggy and terrible. I've > dealt with a lot of it as part of my job over the years and it leads > to a terrible user experience for Linux users. > In general, all of the stuff about Secure Boot and signing is really tangential. This change proposal is about reducing maintenance burden because we already know that pretending to continue to support legacy x86 boot is problematic. As stated in the change proposal, "Community assistance is required to continue the status quo. Current owners plan to orphan some packages regardless of whether the proposal is accepted." By the way, VMware also deprecated legacy x86 boot support: https://kb.vmware.com/s/article/84233 > If you are making UEFI the only way people boot, ***fix*** the > experience. If you're not committed to that, then you're causing more > pain for no gain. > This comment seems misguided, since improving the experience on UEFI systems is precisely what Red Hat's bootloader team* is most focused on. Not stated in this proposal, but continuing to support legacy x86 boot also serves to allow OEMs, IBVs and users from avoiding fixing and reporting issues that should have been fixed a long time ago because there is a mostly palatable workaround. *(NB: a team I manage) -- > 真実はいつも一つ！/ Always, there's only one truth! > _______________________________________________ > 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 > -- Jared Dominguez (he/him) Software Engineering Manager New Platform Technologies Enablement team RHEL Workstation Engineering If I am emailing outside of business hours (mine or yours), it is my choice and does not mean I expect you to respond today.
_______________________________________________ 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
