Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux