GNU Linux-libre Was Mistakenly Including Non-Free Code, So Releases Now Re-Spun + 5.14

GNU Linux-libre 5.14-gnu was released today as the project's re-base on the recently released Linux 5.14 upstream kernel. But prior supported GNU Linux-libre releases also had to be re-spun as it turned out this "100% free software" kernel was mistakenly leaving in some non-free kernel bits.

As for the new changes with GNU Linux-libre 5.14, the Intel "i915" kernel graphics driver needed various alterations for its de-blobbing, the new Emulex Fibre Channel Target (eftc) driver needed to remove support for loading binary blobs, and various blob name changes were needed across various drivers from AMDGPU to others.

So now the GNU Linux-libre 5.14 kernel is all dandy and out there for use on systems that can run without depending upon any of these stripped out binary firmware/microcode blobs and other non-free software components.

But it also turned out GNU Linux-libre was previously missing in some non-free code so in addition to the 5.14 release there is also re-releases for the 4.4, 4.9, 4.14, 4.19, 5.4, 5.10, and 5.13 kernel series too. Here's what happened with this situation:

A little over a week ago, Legimet raised flags on some potential nonfree code in GNU Linux-libre.

Though some of the issues were about different standards (we don't generally regard poorly documented code or pure data as object code over speculation about the existence of an alternate, preferrable source form), but a couple of the issues turned out to be sourceless object code, and so we started the process of cleaning them up, and of respinning earlier releases that contained them.

So now we clean up a firmware patch for vs6624 sensors, and several microcode relocation patches for powerpc 8xx. Both are encoded as arrays of numbers in upstream Linux releases. The latter had long seemed suspicious to me, but I had assumed those who started cleaning up Linux before I inherited Linux-libre had good reasons to leave it in. The former was entirely my own mistake. I was likely fooled by apparently discontiguous address ranges, a pattern that suggests register initialization, but the multiple small fragments are actually larger contiguous ranges (thanks, Juca!), shuffled for reasons unknown.

More details on these happenings via the GNU mailing list.