Re: [GNU-linux-libre] Reviewing ConnochaetOS

[Alexandre Oliva]

On Aug  6, 2017, Henry Jensen <address@hidden> wrote:

> RMS mentions a change "to obfuscate the names of the firmware files"
> instead of failing.

Yeah, he was referring to the "Request for Comments" section at
http://www.fsfla.org/anuncio/2010-03-Linux-2.6.33-libre

> Last time I checked, the situation hasn't changed,

It has changed a lot, actually, but not exactly in a favorable way.

Obfuscating blob names in sources would just create alternate names for
blobs, solving nothing, while turning sources into non-sources under the
GPL: they would no longer be the most convenient way to make changes to
the software.  In order to distribute them, or binaries compiled out of
them, we'd have to distribute the corresponding sources along with them.
Oops ;-)

Also, Linux changed so as to pretty much deprecate the userland hotplug
script used to load firmware.  Its firmware loading machinery can now
look directly in the filesystem, within /lib/firmware or elsewhere.  In
this setting, the idea of one-way-hashing the blob name before passing
it on to the userland hotplug script thus became moot.

Another concern is whether looking blobs up /lib/firmware when it's NFS-
or fuse-mounted is enough of a request to enable it to be construed as
user inducement.  Probably not in FSDG desktop-targeted distros, but GNU
Linux-libre is designed to be installable even in freedom-hostile
distros, so the requirements are more stringent.

We have considered, for example, the possibility of a distro's
fuse-mounting /lib/firmware so that a userland program monitors the
requests and offers to install requested firmware, just the kind of
scenario that motivated us to want to one-way-hash the requests to the
hotplug script.

In an attempt to work around this kind of attack, we considered even
requiring userland to enumerate firmware filenames to the kernel, and
arranging for the kernel to only issue requests to filenames listed in
the enumeration.  The fuse-mounted /lib/firmware could, however, list
all blobs available for on-demand installation, defeating even the
pre-enumeration.

At that point, we decided the problem was not fixable, and that, because
of the design of the firmware-loading machinery, we'd have to keep on
disabling the loading of blobs altogether in order to be on the safe
side WRT inducing their installation.

However, we also agreed that desktop-focused distros, that didn't
attempt to induce and facilitate the installation of blobs by the
above-described means, could very well relax these stringent
requirements, and distribute versions of Linux that didn't completely
disable blob-loading, and just refrained from mentioning the blob names
in logged errors.  I'm not sure the Debian kernel gets that far, I'm
afraid.

-- 
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