A Latin American Free Software Foundation published a fully free version of the Linux kernel 6.12 — Linux-libre 6.12-gnu, cleansed of firmware and driver elements containing non-free components or code segments whose use is limited by the manufacturer. Additionally, Linux-libre disables kernel features for loading external non-free components not included with the kernel and removes references to the use of non-free components from the documentation.
To clean the kernel from non-free parts, the Linux-libre project has created a universal shell script that contains thousands of templates for detecting the presence of binary inserts and excluding false positives. Ready-made patches, created based on the use of the aforementioned script, are also available for download. The Linux-libre kernel is recommended for use in distributions that meet the Free Software Foundation's criteria for building fully free GNU/Linux distributions. For example, Linux-libre is used in distributions such as Dragora Linux, Trisquel, Dyne:Bolic, gNewSense, Parabola, Musix, and Kongoni.
The release of Linux-libre 6.12-gnu includes code for cleaning blobs in drivers for SoC CPM/QE QMC, wireless chips Realtek 8852BE-VT, Bluetooth adapters Amlogic, network adapters amcc qt2025, sensors aw96103/aw96105, and codecs TI TLV320AIC31XX. An additional clean-up of blobs has been performed in drivers for xHCI controllers Renesas and Intel ISH (Integrated Sensor Hub) HID. The blob removal code for drivers and subsystems MHI PCI host, Adreno 620/621, r8169, Qualcomm q6v5 remoteproc, rtw8852c, rtw8922a, as well as in dts files for ARM54 chips TI PRU and Qualcomm has been updated. The clean-up of drivers for wireless cards ks7010 and the Intel SkyLake audio subsystem has been discontinued as these drivers were removed from the kernel.
It is particularly noted that one of the drivers contained executable object code generated from unpublished source texts, embedded in the form of a sequence of hexadecimal numbers. The problematic driver is not explicitly named, but judging by the changes, it seems to refer to the presence of shader microcode in the file gfx_v9_4_3_cleaner_shader.h, part of the AMDGPU driver. The first such insertion was identified in kernel 6.11 and later proposed for removal by one of the developers as the source texts were not provided (a situation arose where a program was delivered under the GPL license, available only in binary form). However, in kernel 6.12, the specified binary code was preserved, and another similar insertion was added to the same driver.
Additionally, the announcement of Linux-libre 6.12 mentioned two more events:
- A kernelfix has been proposed to block Tuxedo laptop drivers from accessing kernel subsystems that are only available for code under the GPLv2 license (EXPORT_SYMBOL_GPL). This blocking capability was initially introduced to restrict proprietary drivers from linking to Linux kernel components exported only for GPLv2-licensed modules, but is successfully circumvented by creating intermediary modules that relay proprietary driver access to the necessary kernel APIs. In the case of Tuxedo drivers, the situation is reversed — despite the fact that Tuxedo drivers are developed separately from the kernel, they are provided under the GPLv3 license, which is incompatible with GPLv2, but advocates for more freedoms, for instance, protection against tivoization.
It is noted that Tuxedo has long suggested changing the license for their drivers, but has continued to provide code under the GPLv3 license while including the macro ‘MODULE_LICENSE(“GPL”)’ in the driver code instead of ‘MODULE_LICENSE(“GPL v3”)’ to gain access to all kernel subsystems. Tuxedo has acknowledged the criticism and changed the license for part of their drivers to GPLv2+ for some components. This change has been applied to the gxtp7380, ite_8291, ite_8291_lb, ite_8297, ite_8297, stk8321, tuxedo_compatibility_check, tuxedo_nb02_nvidia_power_ctrl, and tuxedo_tuxi drivers. More than a dozen drivers have yet to be re-licensed, as changing the license for them requires obtaining consent from third-party developers.
A representative from Tuxedo explained the use of ‘MODULE_LICENSE(“GPL”)’ instead of ‘MODULE_LICENSE(“GPL v3”)’ as arising from a lack of clear documentation stating that the marker ‘GPL’ cannot be used for GPLv3 licensing. He also mentioned that the company intends to transfer their drivers to the main body of the Linux kernel and is thus working on completely rewriting them under the GPLv2 license, taking into account the requirements for kernel components.
- A kernelt developer discusses the initiative to add the flag X86_BUG_OLD_MICROCODE, which signals that an outdated version of CPU microcode is in use on the system. When this flag is set, the system is suggested to be viewed as having potential unpatched vulnerabilities. Attempts to equate the state of a system with outdated microcode to a situation where real unpatched vulnerabilities exist in the code have led to criticism from one of the maintainers of the Linux-libre project.
According to the maintainer of Linux-libre, the kernel should not infringe on users' right to not install unverified proprietary firmware and microcode on their own devices. Discussions about the existence of vulnerabilities should be tied to specific fixes in certain versions of firmware, rather than labeling any systems that do not have the latest microcode installed as vulnerable, regardless of whether vulnerabilities are present in that system and whether the latest firmware contains fixes for any vulnerabilities.
Forrás: opennet.ru
