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 <adf...@hyperbola.info> 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.