gnu-linux-libre
[Top][All Lists]
Advanced

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

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


From: Alexandre Oliva
Subject: Re: [GNU-linux-libre] PureOS added to endorsed distro list - what about the kernel?
Date: Sat, 20 Jan 2018 01:06:21 -0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)

On Jan 16, 2018, Adonay Felipe Nogueira <address@hidden> wrote:

> What if for example the kernel wouldn't reference stuff by file names,
> but instead to bus address or something like that?

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.

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

The idea that Jason referred to was of one-way hashing blob names, and
having the loader script hash available firmware names until it found
one that matched the request, or until it exhausted the list.

Problem is, distros could still pretend to have plenty of files
available (based on what's in the repos), and make the whole set visible
to the script, even if stuff would only be installed on demand, if
actually requested.

This may have seemed far-fetched back when distros just supplied scripts
that would search repos and offer to install firmware requested by the
kernel but not installed, but more recently, the kernel is moving away
from the userland hotplug script and accessing /lib/firmware directly,
and so distros willing to retain such functionality are going to mount
/lib/firmware as a userland filesystem serving out the complete set of
firmware and installing, or offering to install it, when the kernel
actually requests the files.  So our hashing would have to be done
elsewhere, and even then it wouldn't stop the script/filesystem from
installing stuff that was not installed.


Even if we turned the table around and changed the kernel so as to ask
for a list of available firmware before asking for any blobs, and only
requested blobs that were in the list, we would be defeated by this
filesystem: enumerating the (apparently) available files would make it
seem like all blobs are actually installed.

There doesn't seem to be a way to avoid what we're trying to avoid while
still allowing proprietary firmware to be loaded, so...  we don't allow
it.  It's still a bug, but apparently an unfixable one.

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer



reply via email to

[Prev in Thread] Current Thread [Next in Thread]