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: Adonay Felipe Nogueira
Subject: Re: [GNU-linux-libre] PureOS added to endorsed distro list - what about the kernel?
Date: Mon, 05 Feb 2018 15:28:40 -0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)

Thank you very much for the replies.

If I understand it correctly, the current approach does seem to be more
guaranteed indeed.

2018-01-20T01:06:21-0200 Alexandre Oliva wrote:
> 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.



reply via email to

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