Das Kernel von Linux-libre 6.12 ist verfügbar. Lösung von Lizenzproblemen mit den Tuxedo-Treibern.

Die Lateinamerikanische Stiftung für freie Software hat eine vollständig freie Version des Linux-Kernels 6.12 veröffentlicht – Linux-libre 6.12-gnu, das von Elementen von Firmware und Treibern, die nichtfreie Komponenten oder Codeabschnitte enthalten, bereinigt wurde, deren Anwendung durch den Hersteller eingeschränkt ist. Darüber hinaus deaktiviert Linux-libre Kernel-Funktionen zum Laden externer nichtfreier Komponenten, die nicht im Kernel enthalten sind, und entfernt Erwähnungen der Verwendung nichtfreier Komponenten aus der Dokumentation.

Um den Kernel von nicht-freien Teilen zu bereinigen, wurde ein universelles Shell-Skript im Projekt Linux-libre erstellt, das Tausende von Vorlagen zur Erkennung binärer Einfügungen und zur Ausschluss falscher Positiver enthält. Zudem sind fertig erstellte Patches, die auf dem Einsatz des oben genannten Skripts basieren, zum Download verfügbar. Der Linux-libre-Kernel wird für die Verwendung in Distributionen empfohlen, die den Kriterien der Stiftung für freie Software zur Erstellung vollständig freier GNU/Linux-Distributionen entsprechen. Beispielsweise wird Linux-libre in Distributionen wie Dragora Linux, Trisquel, Dyne:Bolic, gNewSense, Parabola, Musix und Kongoni verwendet.

In der Version Linux-libre 6.12-gnu wurde Code zum Bereinigen von Blobs in Treibern für SoC CPM/QE QMC, drahtlosen Chips Realtek 8852BE-VT, Bluetooth-Adaptern von Amlogic, Netzwerkadaptern amcc qt2025, Sensoren aw96103/aw96105 und TI TLV320AIC31XX-Codecs hinzugefügt. Eine zusätzliche Bereinigung von Blobs in Treibern für xHCI-Controller von Renesas und Intel ISH (Integrated Sensor Hub) HID wurde durchgeführt. Der Code zum Entfernen von Blobs in Treibern und MHI PCI-Host-Subsystemen, Adreno 620/621, r8169, Qualcomm q6v5 remoteproc, rtw8852c, rtw8922a sowie in dts-Dateien für ARM54-Chips von TI PRU und Qualcomm wurde aktualisiert. Die Bereinigung der Treiber für drahtlose Karten ks7010 und das Audio-Subsystem Intel SkyLake wurde eingestellt, da diese Treiber aus dem Kernel entfernt wurden.

Besonders hervorzuheben ist der Nachweis eines Treibers in den Quelltexten eines ausführbaren Objektcodes, der aus nicht veröffentlichten Quelltexten generiert und in Form einer Sequenz von Hexadezimalzahlen eingebettet wurde. Der betreffende Treiber wird zwar nicht namentlich genannt, doch deuten die Änderungen auf das Vorhandensein von Mikrocode für den Shader in der Datei gfx_v9_4_3_cleaner_shader.h hin, die Teil des AMDGPU-Treibers ist. Der erste dieser Einspritzungen wurde im Kernel 6.11 entdeckt und anschließend von einem der Entwickler zur Entfernung vorgeschlagen, da die Quelltexte nicht bereitgestellt wurden (es entstand die Situation, dass das Programm unter der GPL-Lizenz nur in binärer Form verfügbar war). Dennoch blieb der angegebene Binärcode im Kernel 6.12 erhalten, und in denselben Treiber wurde eine weitere ähnliche Einspritzung hinzugefügt.

Darüber hinaus werden in der Ankündigung von Linux-libre 6.12 zwei weitere Ereignisse erwähnt:

• Für die Einbindung in den Kernel wurde ein Patch vorgeschlagen, der den Treibern für Tuxedo-Laptops den Zugriff auf Kernel-Subsysteme verweigert, die nur für Code unter der GPLv2-Lizenz verfügbar sind (EXPORT_SYMBOL_GPL). Die Möglichkeit der Blockierung wurde ursprünglich eingeführt, um die Bindung proprietärer Treiber an Kernelkomponenten, die nur für unter der GPLv2-lizenzierte Module exportiert werden, zu beschränken. Dies wird jedoch erfolgreich durch die Erstellung von Zwischenmodulen umgangen, die den Zugang des proprietären Treibers zu den erforderlichen Kernel-APIs übersetzen. Im Fall der Tuxedo-Treiber ist die Situation umgekehrt: Obwohl die Tuxedo-Treiber unabhängig vom Kernel entwickelt werden, sind sie unter der GPLv3-Lizenz verfügbar, die einerseits nicht mit der GPLv2 kompatibel ist, andererseits jedoch mehr Freiheiten verteidigt, zum Beispiel vor TiVoisierung schützt.

  Es wird festgestellt, dass die Unternehmen Tuxedo schon lange vorgeschlagen haben, die Lizenz für ihre Treiber zu ändern, aber sie weiterhin den Code unter der GPLv3-Lizenz bereitstellten und im Treiber-Code das Makro ‚MODULE_LICENSE(„GPL“)‘ anstelle von ‚MODULE_LICENSE(„GPL v3“)‘ verwendeten, um Zugang zu allen Subsystemen des Kernels zu erhalten. Tuxedo hat die Kritik akzeptiert und die Lizenz für einen Teil ihrer Treiber auf GPLv2+ geändert. Diese Änderung wurde auf die Treiber gxtp7380, ite_8291, ite_8291_lb, ite_8297, ite_8297, stk8321, tuxedo_compatibility_check, tuxedo_nb02_nvidia_power_ctrl und tuxedo_tuxi angewendet. Mehr als ein Dutzend Treiber sind derzeit noch nicht umlizenziert, da für die Lizenzänderung die Zustimmung externer Entwickler erforderlich ist.

  Die Verwendung im Code von ‚MODULE_LICENSE(„GPL“)‘ anstelle von ‚MODULE_LICENSE(„GPL v3“)‘ wurde von einem Vertreter von Tuxedo damit erklärt, dass in der Dokumentation zum Kernel keine klare Erklärung vorhanden ist, dass das Markenzeichen „GPL“ nicht für die Lizenz GPLv3 verwendet werden kann. Er erklärte auch, dass das Unternehmen beabsichtigt, seine Treiber in den Hauptteil des Linux-Kernels zu überführen und daher an deren vollständiger Neuschreibung unter der GPLv2-Lizenz arbeitet, unter Berücksichtigung der Anforderungen an die Komponenten des Kernels.

• Die Kernel-Entwickler diskutieren eine Initiative zur Hinzufügung des Flags X86_BUG_OLD_MICROCODE, das signalisiert, dass in dem System nicht die neueste Version des CPU-Mikrocodes verwendet wird. Bei Setzen dieses Flags wird empfohlen, das System als potenziell anfällig für unbehobene Sicherheitslücken zu betrachten. Versuche, den Zustand eines Systems mit veraltetem Mikrokode mit echten unbehobenen Sicherheitsanfälligkeiten im Code gleichzusetzen, führten zu Kritik von einem der Betreuer des Linux-libre-Projekts.

  Nach Ansicht des Betreuers von Linux-libre sollte der Kernel das Recht der Benutzer, unverifizierte proprietäre Firmware und Mikrokode auf ihren eigenen Geräten nicht zu installieren, nicht einschränken. Es wird vorgeschlagen, über das Vorhandensein von Sicherheitsanfälligkeiten in Bezug auf spezifische Korrekturen in bestimmten Versionen von Firmware zu sprechen und nicht alle Systeme, die nicht den neuesten Mikrokode installiert haben, pauschal als anfällig zu bezeichnen, ohne zu prüfen, ob in diesem System Sicherheitsanfälligkeiten vorhanden sind und ob die neueste Firmware Sicherheitsanfälligkeiten behoben hat.

Quelle: opennet.ru