On Tue, Apr 5, 2022 at 9:07 PM Demi Marie Obenour <demioben...@gmail.com> wrote: > > On 4/5/22 16:09, Neal Gompa 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. > > Are you sure about that? There is probably a better place to talk > about this, but Qubes OS also will be needing v4l2loopback soon (for > Qubes Video Companion) and so I have a strong interest in getting it > upstreamed. >
Yes. Last I heard, V4L2 folks think it'd be used to bypass making a real camera driver for the kernel. That's pretty much why it's not there. You may be able to accomplish a good portion of it with PipeWire's camera API, but you'll probably want to ask in the PipeWire Matrix room about that: https://matrix.to/#/#pipewire:matrix.org > > 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. > > > > 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. > > And this ignores the case of virtualized systems, where the EFI System > Partition is purely wasted space. > The partition can be fairly small if it just contains EFI blobs, but I think we give a fairly large one by default. > > 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. > > > > 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. > > And even if it worked great on all platforms, **users should not need > to do it**. > > Because let’s face it: If you have unrestricted root access, getting > kernel access is almost certainly going to be possible. If nothing > else, just boot into Windows and take advantage of any one of the admin > ⇒ kernel privilege escalations known on that platform. For secure > boot to actually be more than security theater, it needs to disallow > insecure OSs (such as Windows) from booting. Secure boot on Android > does that. Secure boot on PCs does not, at least with the default > list of trusted bootloaders. > > Qubes OS (which has security as its very reason for existing) does > *not* use secure boot right now, and while support for secure boot > would be nice, it is *not* the top priority right now. Measured boot, > combined with disk encryption keys tied to these measurements, provides > much more security in practice. If the attacker is at the point > where they can tamper with the bootloader of a running system with the > disks unlocked, they have already won. If this is an offline attack, > measured boot is a much more effective mitigation. > > > 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. > > Bingo. > Indeed. -- 真実はいつも一つ！/ 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
