On Jan 16, 2018, Adonay Felipe Nogueira <[email protected]> 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
