Die lateinamerikanische FSF hat eine vollstĂ€ndig freie Version des Linux-Kernels 6.12 â Linux-libre 6.12-gnu veröffentlicht, die von Firmware- und Treiberelementen befreit ist, die proprietĂ€re Komponenten oder Bereiche von Code enthalten, deren Verwendung vom Hersteller eingeschrĂ€nkt ist. DarĂŒber hinaus deaktiviert Linux-libre die Kernel-Funktionen zum Laden externer proprietĂ€rer Komponenten, die nicht im Kernel-Paket enthalten sind, und entfernt Hinweise auf die Verwendung von proprietĂ€ren Komponenten aus der Dokumentation.
Um den Kernel von nichtfreien Teilen zu befreien, wurde von dem Projekt Linux-libre ein universelles Shell-Skript erstellt, das Tausende von Vorlagen enthĂ€lt, um das Vorhandensein von BinĂ€reinschĂŒben zu erkennen und Fehlalarmierungen auszuschlieĂen. AuĂerdem sind bereits erstellte Patches, die auf der Nutzung 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.
Im Linux-libre 6.12-gnu wurden Code zur Reinigung 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. Es wurde eine zusĂ€tzliche Bereinigung von Blobs in den Treibern fĂŒr die xHCI-Controller Renesas und Intel ISH (Integrated Sensor Hub) HID durchgefĂŒhrt. Der Code zur Blob-Entfernung in Treibern und MHI PCI-Host-Subsystemen, Adreno 620/621, r8169, Qualcomm q6v5 remoteproc, rtw8852c, rtw8922a und auch in dts-Dateien fĂŒr ARM54-Chips TI PRU und Qualcomm wurde aktualisiert. Die Treiber fĂŒr die drahtlosen Karten ks7010 und das Audiosubsystem Intel SkyLake wurden nicht mehr gereinigt, da diese Treiber aus dem Kernel entfernt wurden.
Besonders hervorzuheben ist die Entdeckung in den Quelltexten eines Treibers eines ausfĂŒhrbaren Objektcodes, der aus nicht veröffentlichten Quelltexten generiert und in Form einer Sequenz von hexadezimalen Zahlen eingebettet wurde. Der problematische Treiber wird nicht namentlich genannt, aber den Ănderungen zufolge bezieht sich das auf das Vorhandensein von Mikrocode des Shaders in der Datei gfx_v9_4_3_cleaner_shader.h, die Teil des AMDGPU-Treibers ist. Der erste Ă€hnliche Eintrag wurde im Kernel 6.11 gefunden und dann von einem der Entwickler zur Entfernung vorgeschlagen, da die Quelltexte nicht bereitgestellt wurden (es entstand eine Situation, in der ein unter der GPL-Lizenz bereitgestelltes Programm nur im BinĂ€rformat verfĂŒgbar war). Dennoch wurde im Kernel 6.12 der angegebene BinĂ€rcode beibehalten und dem gleichen Treiber wurde ein weiterer Ă€hnlicher Eintrag hinzugefĂŒgt.
DarĂŒber hinaus wurden in der AnkĂŒndigung von Linux-libre 6.12 noch zwei weitere Ereignisse erwĂ€hnt:
- Um in den Kern aufgenommen zu werden, wurde eine Korrektur vorgeschlagen, die Treibern fĂŒr Tuxedo-Laptops den Zugang zu den fĂŒr nur GPLv2-lizenzierten Code zugĂ€nglichen Untersystemen des Kernels (EXPORT_SYMBOL_GPL) blockiert. Diese Blockierung wurde ursprĂŒnglich eingefĂŒhrt, um die Bindung proprietĂ€rer Treiber an Kernelkomponenten zu beschrĂ€nken, die nur fĂŒr Module unter GPLv2 lizenziert sind. Sie wird jedoch erfolgreich umgangen, indem Schichtmodule erstellt werden, die den Zugriff des proprietĂ€ren Treibers auf die erforderlichen Kernel-APIs ĂŒbersetzen. Im Fall der Tuxedo-Treiber ist die Situation umgekehrt: Trotz der Tatsache, dass Tuxedo-Treiber unabhĂ€ngig vom Kernel entwickelt werden, werden sie unter der GPLv3-Lizenz geliefert, die einerseits nicht mit der GPLv2 kompatibel ist, andererseits jedoch mehr Freiheiten verteidigt, z.B. vor Tivoisierung schĂŒtzt.
Es wird angemerkt, dass die Firma Tuxedo seit langem vorgeschlagen hat, die Lizenz fĂŒr ihre Treiber zu Ă€ndern, aber sie weiterhin Code unter der GPLv3-Lizenz liefert und im Treibercode das Makro 'MODULE_LICENSE("GPL")' anstelle von 'MODULE_LICENSE("GPL v3")' angibt, um Zugang zu allen Untersystemen des Kernels zu erhalten. Die Firma 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 noch nicht umlizenziert, da fĂŒr eine LizenzĂ€nderung die Zustimmung von Drittentwicklern eingeholt werden muss.
Die Verwendung von 'MODULE_LICENSE("GPL")' anstelle von 'MODULE_LICENSE("GPL v3")' wurde von einem Vertreter von Tuxedo mit dem Fehlen einer klaren ErklĂ€rung in der Kernel-Dokumentation begrĂŒndet, dass das Kennzeichen âGPLâ nicht fĂŒr die GPLv3-Lizenz verwendet werden kann. Er erklĂ€rte auch, dass das Unternehmen plant, seine Treiber in den Hauptkern von Linux zu ĂŒberfĂŒhren und zu diesem Zweck daran arbeitet, sie vollstĂ€ndig unter der GPLv2-Lizenz unter BerĂŒcksichtigung der Anforderungen an die Kernelkomponenten neu zu schreiben.
- Die Kernel-Entwickler diskutieren die Initiative zur EinfĂŒhrung des Flags X86_BUG_OLD_MICROCODE, das signalisiert, dass im System keine aktuelle Version des CPU-Mikrocode verwendet wird. Bei Aktivierung dieses Flags wird empfohlen, das System als potenziell verletzbar zu betrachten. Versuche, den Zustand eines Systems mit nicht aktualisiertem Mikrocode gleichzusetzen mit der Situation vorhandener tatsĂ€chlicher nicht behobener SicherheitslĂŒcken im Code, stieĂen auf Kritik von einem der Betreuer des Linux-libre-Projekts.
Laut dem Betreuer von Linux-libre sollte der Kernel das Recht der Benutzer nicht einschrĂ€nken, nicht geprĂŒfte proprietĂ€re Firmware und Mikrocode auf ihrem eigenen GerĂ€t nicht zu installieren. Die Diskussion ĂŒber die Existenz von SicherheitslĂŒcken sollte an konkrete Korrekturen in bestimmten Versionen von Firmware gebunden sein und nicht alle Systeme als verletzbar kennzeichnen, die nicht den neuesten Mikrocode installiert haben, ohne zu analysieren, ob in diesem System SicherheitslĂŒcken vorhanden sind und ob die aktuelle Firmware Korrekturen fĂŒr SicherheitslĂŒcken enthĂ€lt.
Quelle: opennet.ru
