Kernel-Log: Proprietäre Linux-Treiber stolpern und lösen Debatten aus

Während der zu Linux 2.6.25 führende Entwicklerzweig den Nvidia-Treibern nur vorübergehend ein Bein stellte, sieht es so aus, als würde die nächste Kernel-Version den Einsatz von USB-NDIS-Treibern via Ndiswrapper unterbinden.

In Pocket speichern vorlesen Druckansicht 766 Kommentare lesen
Lesezeit: 5 Min.
Von
  • Thorsten Leemhuis

Tester von Vorabversionen des Linux-Kernels 2.6.25 stolpern derzeit über verschiedene Probleme mit proprietären Treibern. So arbeiteten die Kernel-Module des Nvidia-Grafiktreiber zwischenzeitlich nicht, da die Kernel-Entwickler die Schnittstelle init_mm nicht mehr exportieren. Auf die Frage, ob die Kernel-Entwickler diese Änderung rückgängig machen könnten, zeigte sich ein Entwickler wenig kooperationsbereit. Später legt er sogar nochmal nach und kritisiert Nvidia deutlich. Nichtsdestotrotz wurde die Änderung im Entwicklerzweig anschließend zurückgenommen. Aber nur vorübergehend, denn mit Linux 2.6.26 soll init_mm dann in wenigen Wochen wieder verschwinden; das soll den Entwickler von externen Kernel-Modulen – genannt wurden die für VirtualBox – Zeit geben, ihren Code anzupassen.

Auch der Ndiswrapper lässt sich derzeit nicht so recht mit den Vorabversionen von 2.6.25 einsetzen, da der Kernel sich beim Laden des Ndiswrappers selbst als Tainted (verschmutzt, befleckt) markiert und das wiederum dem Ndiswrapper auch den Zugriff auf ausschließlich für GPL2-kompatible Treiber freigegebene Schnittstellen verwehrt. Das hatte bereits ein früheres Kernel-Log erläutert – damals sah alles danach aus, als würden die Entwickler die Änderung zügig rückgängig machen.

Das ist aber nicht passiert. Als dann Ende vergangener Woche ein entsprechender Patch an die Linux-Kernel Mailing List (LKML) gesandt wurde, kritisierte Linus Torvalds den Patch nachhaltig. Er würde nicht einsehen, warum Ndiswrapper eine Spezialbehandlung bräuchte. Wenn der Ndiswrapper Nicht-GPL-Module lädt, dann dürfe er auch keine als GPLONLY markierte Schnittellen nutzen ("I'm not seeing why ndiswrapper should be treated separately. If it loads non-GPL modules, it shouldn't be able to use GPLONLY symbols. [...]"). Später fügt er noch hinzu, dass Ndiswrapper selbst nicht kompatibel zur GPL sei. Im Rahmen der länglichen Diskussion führt er diese und andere Argumente gegen die Änderung noch weiter aus.

Dabei kommt auch die im Kernel-Log bereits beschriebene und für 2.6.25 vorgesehene Änderung an der USB-API zur Sprache, mit der die USB-Entwickler klarzustellen versuchen, dass nur noch unter der GPL2 oder kompatiblen Lizenzen stehende USB-Treiber zentrale Funktionen des Kernel-internen USB-Treiber-API nutzen dürfen. Das würde der Ndiswrapper aber umgehen, da er sich selbst als GPL-kompatibel gibt, aber dann nicht GPL-kompatiblen Code in Form der für Windows geschriebenen NDIS-Treiber lädt. Dieser würde somit indirekt die via EXPORT_SYMBOL_GPL freigegebenen USB-Schnittstellen nutzen.

Ob das legal ist, dürfte vermutlich auch bei mit Software-Lizenzen vertrauten Juristen umstritten sein, sodass es nur Richter im Gerichtssaal klären könnten – so weit kommt es aber meist gar nicht, sodass erst einmal viel wichtiger sein wird, was die Kernel-Entwickler machen. Wenn alles so bleibt, wie es ist, hat der Ndiswrapper keinen Zugriff auf via EXPORT_SYMBOL_GPL freigegebene Schnittstellen – da das bei 2.6.25 unter anderem bei zentralen USB-Schnittstellen der Fall ist, wird der Ndiswrapper zumindest für USB-Netzwerk-Hardware mit dem "offiziellen" Linux 2.6.25 nicht richtig funktionieren.

Kernel-Log-Staccato:

  • X.org 7.4 soll nach derzeitigen Planungen Ende April zusammen mit Fedora 9 erscheinen.
  • Die Linux-Entwickler diskutieren den Central regulatory Domain Agent (CRDA), ein Userspace-Programm, das WLAN-Hardware so einstellen soll, dass sie die jeweiligen regionalen Richtlinien und Gesetze zum Betrieb von WLANs erfüllt.
  • Die Entwickler von BadRAM versuchen die Kernel-Hacker davon zu überzeugen, die seit Langem existierende Linux-Erweiterung in den offiziellen Kernel zu integrieren. Mit BadRAM kann man den Kernel anweisen, defekte Bereiche von Speichermodulen nicht zu nutzen – etwa um ein Notebook weiterzubenutzen, das defekten Speicher enthält, der auf das Mainboard gelötet ist.
  • Vom kürzlich erwähnten Programm Hdparm steht mittlerweile in den Versionen 8.5 und 8.6 bereit, die einige sicherheitskritische Lücken der vorangegangenen 8er-Versionen korrigieren.
  • Der bisher vergleichsweise wenig in Erscheinung getretene Kernel-Entwickler Oliver Pinter plant, die Linux-Version 2.6.22 im Rahmen der "-op" Kernel-Reihe in Zukunft weiter zu pflegen, nachdem die Verwalter der Stable-Kernel-Series vor Kurzem mit 2.6.22.19 die wohl letzte 2.6.22-Variante veröffentlichten.

Weitere Hintergründe und Informationen rund um Entwicklungen im Linux-Kernel und dessen Umfeld finden sich auch in den vorangegangen Ausgaben des Kernel-Logs auf heise Open: