Re: [GNU-linux-libre] PureOS added to endorsed distro list - what about the kernel?

[Jason Self]

> i must say though that it did not address what is the actual
> behavior preventing the debian kernel from being acceptable, 

I thought it did.

> why is it not possible to simply change or suppress the error
> message printed to the log or to later or periodically scrub the 
> logs of the naughty bits

Because the kernel is not necessarily responsible for all firmware
loading.

Alexandre mentioned this in:

> It's not just about the error messages, it's also about what the
> kernel actually requests of the userland helper script or the
> filesystem serving /lib/firmware, and how distros might configure
> the loader or the filesystem to respond to such requests.

Once the kernel has identified that a firmware is needed for something
then we've got the problem he mentioned:

> When the kernel starts the helper script, it's active telling a
> third-party program "get me a copy of the program foo.bin".

Being that the userland firmware loading program is a separate program
the kernel has no control over what it might do. Absolutely none. It
might log the request, which would be separate from the kernel
logging, and so even if the kernel's logging functionality were
changed in some way it would not have any impact on what this other
program is doing.

But, of course, it could be even worse than logging. It could, for
some examples:

* Display dialog boxes "Hey, this thing is missing. Do you to install
it?" This would be along the lines of how messages are shown about
missing audio/video codecs when you try to play a video. That is
probably even worse that logging because it's right up there, in your
face.

* Automatically download and install it without even asking anything.

* Who knows what else. Being that the userland firmware loading
program is a program, it could do anything that a program could do.
Even things that we aren't currently thinking of.

One might be tempted to say "well, the solution, then, is that -- in
addition to neutering the kernel's logging functionality -- to this to
get rid of the kernel's support for loading firmware from userland,
since it can access the file system directly anyway."

But that is already reducing the kernel's support for loading
firmware, which was part of the original complaint, and doesn't really
address the potential things that could happen: Another problem is
that /lib/firmware could be treated specially by the distro where any
& all of the kernel's attempts to access files there actually succeed
even if the files are not there (Alexandre mentioned the possibility
that the distro mounts /lib/firmware as a separate file system under
FUSE but that would not be the only possible way of doing this), and
then proceed to do exactly the same things that were mentioned as
being problems with the userland firmware helper. In this case another
program is *still* responsible for handling the request and the worse
part is that the kernel would probably not even know this.

Of course, some might be tempted to say that "OK, the solution, then,
is that -- in addition to neutering the kernel's logging functionality
and getting rid of the kernel's support for loading firmware from
userland, it should only try to load firmware when it's not mounted as
a separate file system. Or something." But at point you're starting to
reduce the kernel's ability to load firmware even further, which is
one of the issues that people have raised, and I don't know that there
is a way for the kernel to be able to know the attempt to access the
file system will be handled.

The fundamental problem is with firmware loading being outsourced to
separate programs, regardless of whether the kernel can detect that
this is happening or not. It might not even be able to detect it. And
the kernel has absolutely no control over what that separate program
does after the kernel has made the request via userland or attempted
to access it directly via the file system.

Of course, FSF-endorsed distros would never do any of these things but
Linux-libre is for use by everyone, even those on what Alexandre
called "hostile" distros, and all such cases need to be considered and
handled.

Given all of these possibilities the firmware loading problem may very
well be unsolvable. It's at least very difficult, which is why it
hasn't happened already.