On Tue, Apr 5, 2022 at 9:07 PM Demi Marie Obenour demiobenour@gmail.com wrote:
On 4/5/22 16:09, Neal Gompa wrote:
On Tue, Apr 5, 2022 at 3:38 PM Adam Jackson ajax@redhat.com wrote:
On Tue, Apr 5, 2022 at 3:15 PM Neal Gompa ngompa13@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.