On Mon, 14 Apr 2025 10:52:31 +0200 Simon Josefsson <si...@josefsson.org> wrote: > > Last time I discussed it with the linux-libre, the reason loading > > non-free firmware is outright disabled is because it'd be trivial > > for any privileged (or maybe that's not even a condition?) > > processes to make a system call to Linux to load non-free firmware, > > which would make it difficult to control for users. > > Oh, is that really the case? I had assumed that this was a policy > decision, that linux-libre didn't want to allow users to have the > ability to load non-free firmware, to make sure the goals of > linux-libre aren't compromised. Note that some firmwares can probably also be loaded from userspace without having Linux involved.
I remember having to remove nonfree firmware in SDR related packages in
Parabola, in that case the firmware was for some FPGAs and it was
nonfree in practice because it required nonfree tools to be "compiled"
(the technical term is synthesized for FPGAs). These can probably be
loaded with some utility that talks to some USB device directly with
libusb.
Nowadays there are probably drivers for that kind of things, so I'm
unsure what is the current practice.
So in practice linux-libre only prevent the kernel from picking some
firmwares put in /lib/firmware.
But my understanding was that in the case of linux-libre that was a
bug not a feature.
> Is the syscall available for non-root users? If so isn't that a linux
> kernel bug, surely non-privileged users shouldn't be allowed to load
> firmware that can modify hardware behaviour?
There is no syscall. You can do it by hand with echo and cat.
It works in this way:
# echo 1 > /sys/class/firmware/loading
# cat /lib/firmware/my-firmware.bin > \
/sys/class/firmware/data
# echo 0 > /sys/class/firmware/loading
If I remember well, to run that at the right moment, there is also an
interface to be notified when a firmware is requested. But that can
also be done with a shell command:
# nano /bin/my-udev-replacement
# echo /bin/my-udev-replacement > /proc/sys/kernel/hotplug
I don't remember how firmware request look like though. It's been many
years since I last used that.
> I have thought that a middle ground project like 'linux-free' would be
> possible: it would be identical to linux-libre but re-add the hooks to
> allow root to load non-free firmware, if they so chose to do it. I'm
> more comfortable with this approach than using linux upstream, since I
> think that linux-libre improves more than just non-free firmware
> loading.
Indeed. It makes some GPU work.
> I don't think a strict kernel policy to disallow users to run non-free
> code serves user freedom: it would prevent running a binary that I
> build using GCC built on a 5 lines C code that doesn't have a license
> (such a program would also be non-free).
There is also another consequence: it doesn't print the firmware name,
so users are not steered toward finding it and putting it in
/lib/firmware, though I'm unsure how much that steers people in
practice. For instance are there cases where some software parses the
kernel logs and popups shows up when you don't have firmwares? If we
don't package that we are probably OK.
Another consequence I see is that it makes refusing these firmware
harder, though I'm unsure if it happens in practice for firmwares.
Do project that indirectly depend on 3D acceleration or nonfree firmware
treat users the same if they don't want to use the nonfree firmware or
if they can't ?
The Radeon probably doesn't count here because if in practice the
upstream for users is linux-libre or Guix (they would report bugs
there), it probably doesn't bring any pressure to install the
nonfree firmwares.
If the upstream is Gnome in practice, that may or may not have a
collective impact, but they also need to make Gnome work in VMs without
3D acceleration, so the question is more when to enable it to work
without 3D acceleration (this could be hardcoded or configurable at
runtime, I'm unsure, dllud looked into it for Replicant few years ago,
but at least patching mesa and/or gnome source code can always make it
work, the question is also if it works in Guix, and if not are we
willing to make it work to make sure to remove pressure and make
everybody happy, effectively improving both freedom and also the
ability to use nonfree firmwares).
A decision probably would have no impact on some software that
really depend on 3D accelerations like some games unless the CPU is
fast enough to run llvmpipe (and in this case it's the same issue as
above: is it configured to run llvmpipe or does it just fail, do we
need to patch mesa?).
For communication software like skype, this is way more documented as it
did happen a lot though: some people were really pressured by other
people to install it and use it, so we can clearly say there was
pressure here.
Note that if we manage to patch/configure MESA it could also help
support more hardware in general (computers with out of tree GPU drivers
or nonfree drivers that users don't want to use, or even can't use,
etc. That may happen on some ARM/RISCV computers, or some x86 tablets
with a PowerVR GPU).
In general I think it could be a good idea to find solution that also
make Guix better at the same time.
> Maybe this topic could be brought up again on the linux-libre list, I
> don't recall any recent discussion about this...
I discussed it for Replicant and only got vague answers[1].
References:
-----------
[1]Date: Thu Oct 14 00:11:40 UTC 2021
From: same mail than I'm sending from
Subject: Linux-libre architecture and how to modify it for
other uses cases?
Link: [2]
[2]https://www.fsfla.org/pipermail/linux-libre/2021-October/003446.html
Denis.
pgpCaQNTuJ__S.pgp
Description: OpenPGP digital signature
