- Die Linux-Kernel-Community steht proprietären Kernel-Modulen seit Langem ablehnend gegenüber, und der Patch von Christoph Hellwig ist ein weiterer Schritt, diese Schlupflöcher erneut zu verengen
- Der Kernel verbietet das Laden proprietärer Module nicht grundsätzlich, erlaubt über GPL-only exports aber den Zugriff auf bestimmte Kernel-Symbole nur für GPL-kompatible Module
- 2020 wurde ein GPL condom-Ansatz bekannt, bei dem ein GPL-Modul als Brücke zwischen proprietärem Modul und Kernel dient; seitdem werden auch Module, die proprietäre Symbole verwenden, als proprietär behandelt
- Das neue Schlupfloch nutzt
symbol_get(), um Adressen interner Symbole proprietärer Module ohne das normale Import-Verfahren zu erhalten; Hellwig geht davon aus, dass NVIDIA den Code dafür entsprechend angepasst hat - Der vorgeschlagene Patch lässt
symbol_get()bei der Suche nach nicht als GPL-only markierten Symbolen fehlschlagen und schließt so diese Umgehung, auch wenn sich Zugriffskontrollen nur schwer vollständig absichern lassen, solange Module im Kernel-Adressraum laufen
Alte Spannungen rund um proprietäre Kernel-Module
- Die Linux-Kernel-Community hat seit jeher kein reibungsloses Verhältnis zu Anbietern proprietärer Kernel-Module
- Solche Module lassen sich außer von ihren Erstellern nur schwer debuggen oder korrigieren
- Viele Entwickler sehen darin einen Verstoß gegen die Kernel-Lizenz und das Urheberrecht am Code
- Dennoch wurden proprietäre Module in einem gewissen Rahmen zugelassen
- Der jüngste Patch von Christoph Hellwig ist ein Schritt, diesen Spielraum weiter einzuengen
Der Versuch von 2006, das Laden zu verbieten, und GPL-only exports
- 2006 gab es einen kurzen Versuch, das Laden proprietärer Kernel-Module vollständig zu verbieten
- Linus Torvalds stoppte diesen Versuch aus mehreren Gründen
- Das bloße Laden proprietärer Module in den Linux-Kernel ist an sich keine Urheberrechtsverletzung
- Linux-Nutzer dürfen so etwas tun
- Torvalds sah in einem solchen Verbot das Signal, dass es eher um Lizenzstreitigkeiten als um technische Verbesserungen geht
- Die Verbreitung proprietärer Module kann eine Urheberrechtsverletzung darstellen, wenn es sich bei ihnen um abgeleitete Werke des Kernel-Codes handelt
- Ob ein abgeleitetes Werk vorliegt, ist jedoch unklar, und der Kernel selbst kann diese Bewertung kaum tatsächlich vornehmen
- Im Kernel gibt es mit GPL-only exports seit Langem einen Mechanismus, um potenziell problematische Module auszubremsen
- Kernel-Module müssen auf vom Kernel exportierte Funktions- und Datenstruktur-Symbole zugreifen, um nützliche Arbeit zu leisten
- Viele Symbole sind nur für Module freigegeben, die eine GPL-kompatible Lizenz deklarieren
- Dadurch werden proprietäre Module von erheblichen Teilen der Kernel-Funktionalität ferngehalten
Die Absicht hinter der GPL-only-Markierung und die Realität
- Theoretisch bedeutet eine GPL-only-Markierung, dass ein Symbol so tief mit dem Kernel-Inneren verbunden ist, dass Code, der es nutzt, zwangsläufig ein abgeleitetes Werk des Kernels wäre
- In der Praxis führen Entwickler eine solche juristische Analyse nicht durch
- Meist sind sie dafür auch gar nicht qualifiziert
- Tatsächlich wird das Markieren von Symbolen als GPL-only oft einfach als Mittel genutzt, proprietäre Module allgemein schwieriger zu machen
Die 2020 bekannt gewordene Umgehung über einen Vermittler
- Hersteller proprietärer Module suchen seit Langem nach Wegen, die Beschränkungen von GPL-only exports zu umgehen
- Eine Möglichkeit wäre, fälschlich eine GPL-kompatible Lizenz zu deklarieren, doch das wirkt wie ein offenes Eingeständnis von Fehlverhalten und wird von Unternehmen instinktiv gemieden
- Eine subtilere Methode wurde 2020 im Zusammenhang mit einer Patch-Serie zu Peer-to-Peer-DMA sichtbar
- In dieser Konstruktion dient ein Modul mit deklarierter GPL-kompatibler Lizenz als Vermittler
- Dieses Modul kann auf alle vom Kernel exportierten Symbole zugreifen
- Importiert es anschließend Symbole eines proprietären Moduls, kann der proprietäre Code auf die benötigten Kernel-Funktionen zugreifen
- Das ist eine Variante des sogenannten GPL condom
Der Gegenpatch von 2020
- Hellwig ließ damals einen Patch einfließen, der dieses Vorgehen erschweren sollte
- Im aktuellen Kernel werden Module, die Symbole proprietärer Module verwenden, ebenfalls als proprietär behandelt
- Sie verlieren damit sofort den Zugriff auf GPL-only-Symbole
- Wer bereits GPL-only-Symbole nutzt und dann Symbole proprietärer Module importieren will, scheitert ebenfalls
- Diese Prüfung blockiert den Weg, auf dem ein GPL-Modul als Vermittler zwischen proprietärem Modul und Kernel fungieren kann
Das neue Schlupfloch über symbol_get()
- Der Kernel stellt das Makro
symbol_get()bereit; die eigentliche Arbeit übernimmt__symbol_get() - Diese Funktion sucht die mit einem Kernel-Symbol verknüpfte Adresse
symbol_get()ist seit dem Release 2.5.48 von 2002 im Kernel vorhanden und wurde bei einer umfassenden Überarbeitung des Modul-Laders hinzugefügt- Es gibt dabei eine wichtige Einschränkung
- Es werden nur Symbole nachgeschlagen, die von ladbaren Modulen bereitgestellt werden
- Gedacht ist es für eng gekoppelte Module, die ohne Referenzzyklen damit umgehen müssen, dass eine Seite möglicherweise noch nicht geladen ist
- Oberflächlich betrachtet scheint das für Anbieter proprietärer Module wenig hilfreich zu sein, weil sich damit keine GPL-only-Kernel-Symbole finden lassen und die Regeln also nicht direkt umgangen werden können
Wie symbol_get() die Abwehr von 2020 umgeht
- Mit
symbol_get()lassen sich Adressen proprietärer Module ermitteln, ohne den normalen Import-Mechanismus und dessen Beschränkungen zu durchlaufen - Dadurch kann die 2020 eingeführte Abwehr erneut umgangen werden
- Ein nominell GPL-lizenziertes Modul kann ein proprietäres Modul aufrufen
- Dieses proprietäre Modul kann dann auf die benötigten Kernel-Funktionen zugreifen
- Hellwig geht davon aus, dass NVIDIA den Code so angepasst hat, dass diese Umgehung genutzt wird
Verhaltensänderung durch die neue Patch-Serie
- Um dieses Loch erneut zu schließen, hat Hellwig eine Patch-Serie eingereicht und später auch eine überarbeitete Fassung vorgelegt
- Die zentrale Änderung besteht darin, das Verhalten von
symbol_get()anzupassen- Wenn das gesuchte Symbol nicht als GPL-only markiert ist, schlägt der Aufruf fehl
- Das ist die umgekehrte Richtung der sonst üblichen Prüfung, die normalerweise den Zugriff auf GPL-only-Symbole verweigert
- Der Grund ist, dass
symbol_get()ursprünglich für niedrigstufige Zusammenarbeit tief im Kernel gedacht war, wo ohnehin erwartet wird, dass alles GPL-only ist - Einige bestehende Verwendungen im Kernel zielten bislang auf Symbole, die nicht als GPL-only markiert waren
- Die Patch-Serie enthält daher auch Änderungen, die diese Symbole auf GPL-only umstellen
Erwartete Auswirkungen und Grenzen
- Diese Änderung an
symbol_get()macht es unmöglich, dass GPL-lizenzierte Kernel-Module mitsymbol_get()interne Symbole proprietärer Module auflösen - Wenn diese Änderung in eine Mainline-Version aufgenommen und von Distributionen übernommen wird, müssen Entwickler proprietärer Module andere Wege finden, um den benötigten Zugriff auf Kernel-Interna zu erhalten
- Da der Modul-Maintainer Luis Chamberlain diese Änderung bereits übernommen hat, stehen die Chancen auf Aufnahme in den Mainline-Kernel recht gut
- Dieser Konflikt besteht seit Langem, und es ist keineswegs unwahrscheinlich, dass Autoren proprietärer Module weitere Wege finden, die Absicht der Kernel-Community zu umgehen
- Module laufen unabhängig von ihrer Lizenz im Kernel-Adressraum
- Für Module, die die Symbol-Zugriffsregeln des Kernels umgehen wollen, gibt es eine große Angriffsfläche
- Dieser Bereich lässt sich nur schwer vollständig absichern
- Praktisch bleibt als beste Option, den Vertrieb von reinen Binär-Kernel-Modulen so unbequem wie möglich zu machen, damit Anbieter weiterhin zu frei lizenzierten Lösungen gedrängt werden
- Perfekt ist dieser Ansatz nicht, aber über die Jahre hinweg war er oft wirksam
1 Kommentare
Meinungen auf Hacker News
Der Linker-Code des Linux-Kernels ist darauf ausgelegt, Linus Torvalds’ Auslegung davon durchzusetzen, wie GPL und die System-Call-Ausnahme funktionieren sollen. Daher scheint es rechtlich Raum für die Behauptung zu geben, Nvidia habe einen Urheberrechtsschutz umgangen (DMCA 1201).
Linus würde das in der Praxis wohl nicht tun, und es wäre auch ziemlich schrecklich für das gesamte FOSS-Ökosystem, aber angesichts dessen, was Nvidia bisher so getrieben hat, würde man es fast gern einmal sehen.
Wenn nicht einmal Linux, der 800-Pfund-Gorilla im Raum, bereit ist, vor Gericht zu gehen, sehen die Aussichten für die übrigen Projekte auch nicht rosig aus.
Wenn Linux bei offensichtlichen Lizenz- und Urheberrechtsverletzungen großer Unternehmen nur „sanften“ technischen Druck ausübt, könnte man fast meinen, die GPL sei am Ende, und es wäre besser, zu etwas wie BSD3 oder MIT+Apache zu wechseln.
LLVM setzt kein starkes Copyleft ein und bringt Upstream-Zusammenarbeit mit rein technischen Mitteln wie API-Änderungen und einem sehr hohen Entwicklungstempo voran; das funktioniert ziemlich gut, ohne die gewählte Lizenz zu verwässern.
Eine Gegenklage, die Nvidias Geschäftschancen tatsächlich beeinträchtigen könnte, kann als Abschreckung gegen künftige Probleme gut funktionieren.
Sinngemäß: „Da symbol_get ursprünglich nur für eng kooperierende Module gedacht war, die sehr interne Symbole verwenden, ist es logisch, es auf die Nutzung nur mit EXPORY_SYMBOL_GPL zu beschränken und Nvidia so eine teure Klage wegen Umgehung von DMCA-Zugangskontrollen zu ersparen.“ Das ist eine sehr gelungene Spitze gegen Nvidia dafür, Absicht und Rücksichtnahme offen zu ignorieren und einfach nach eigenem Gutdünken zu handeln.
Träumen darf man ja :)
[1]: https://www.youtube.com/watch?v=tQIdxbWhHSM
Linus hat da keine Sonderbefugnis.
Der Kommentar des Autors dieses Patches ist wirklich ungewöhnlich.
https://lore.kernel.org/lkml/20230731083806.453036-6-hch@lst...
Dort heißt es: „Da symbol_get ursprünglich nur für eng kooperierende Module gedacht war, die sehr interne Symbole verwenden, ist es logisch, es auf die Nutzung nur mit EXPORY_SYMBOL_GPL zu beschränken und nvidia so eine teure Klage wegen Umgehung von DMCA-Zugangskontrollen zu ersparen.“
Das ist wörtlich ein Versuch, für den Linux-Kernel als Open-Source-Projekt den Schutz der Anti-Umgehungsbestimmungen des DMCA geltend zu machen, die die Umgehung von DRM illegalisieren.
Gleichzeitig ist es auch ein implizites Eingeständnis, dass EXPORT_SYMBOL_GPL eindeutig ein DRM-System ist.
Persönlich mag ich NVIDIA nicht und habe auch nicht vor, ihr Verhalten groß zu verteidigen, aber es überrascht mich, dass das Linux-Projekt behauptet, Anti-Umgehungsrecht für DRM gelte auch für Open-Source-Projekte.
Das ist eines der Gesetze, die in der Open-Source-Community nahezu universell abgelehnt werden, und jede Art von DRM-System scheint den Werten von FOSS ziemlich zu widersprechen.
Das Kernziel der GPL war ja gerade, das Urheberrecht gegen das Urheberrecht einzusetzen, also Copyleft.
Je stärker das Urheberrecht wird, desto stärker wird auch der Schutz der GPL. Daher passt es meiner Meinung nach durchaus zum Geist der GPL, zusätzliche urheberrechtliche Regelungen zum Schutz von Open-Source-Software zu nutzen.
Die GPL ist keine permissive Lizenz, sondern eine starke Copyleft-Lizenz, und sie hat reale Durchsetzungskraft.
Der Taint-Mechanismus ist keine Heuchelei, sondern Open Source; wenn der Code unter der GPL steht, kann man damit machen, was man will.
Er ist buchstäblich ein Mittel, um die Link-Bestimmungen der GPL-Lizenz durchzusetzen.
Wenn nötig, muss man es nutzen; daher wirkt das für mich überhaupt nicht seltsam.
Wenn jemand etwas Fragwürdiges getan hat und ihm so sanft ermöglicht wird, das Gesicht zu wahren, hat er ziemlich Glück.
DRM zur Verhinderung von GPL-Missbrauch scheint der logische nächste Schritt zu sein.
Ich verstehe nicht, warum proprietäre Treiber nicht mit einem freien Kernel interagieren dürfen sollten.
Linux implementiert buchstäblich DRM auf Kernel-Ebene, also genau das, was freie Software zu zerstören geschworen hatte.
Zumindest wirkt die Anforderung, proprietäre Treiber daran zu hindern, mit GPL-only-Code zu interagieren, aus meiner Sicht eher wie eine EULA.
Wenn es nur die GPLv2 gäbe, wären proprietäre Module wahrscheinlich eine Verletzung.
Weil Linus aber ausdrücklich festgelegt hat, dass Systemaufrufe das Copyleft der GPL nicht auslösen, lösen auch Kernel-Symbole, die Systemaufrufen entsprechen, das GPL-Copyleft nicht aus.
Um also gemäß Linus’ Auslegung der GPL-Ausnahme einen Lizenzverstoß zu vermeiden, braucht man einen Loader, der anhand von Lizenzdaten prüft, welche Symbole gelinkt werden dürfen und welche nicht.
Das ist tatsächlich DRM auf Kernel-Ebene[0], und Linus könnte möglicherweise auch rechtliche Ansprüche gegen Nvidias Umgehung des Kopierschutzes geltend machen.
GPLv3 schließt jeden Kopierschutz im abgedeckten Code ausdrücklich aus, sodass sie solche Klagen theoretisch verhindern könnte; diese Klausel wurde aber nicht vor Gericht geprüft, und Linus lehnt GPLv3 besonders ab, weil sie die TiVo-Klausel hinzugefügt hat[1].
Diese Funktion wurde vor Jahrzehnten implementiert, und das ursprüngliche Ziel war, keine Bugreports über Abstürze des Linux-Kernels wegen nicht behebbarer proprietärer Module zu bekommen.
Die Durchsetzung der GPL war ein Nebeneffekt.
[0] Nicht zu verwechseln mit dem anderen DRM im Kernel, dem Direct Rendering Manager.
[1] Er hasst nicht so sehr die TiVo-Klausel an sich, sondern dass Bedingungen rückwirkend zu v2-Software hinzugefügt und die Geschäftsbedingungen geändert werden. Es fühlt sich für ihn so an, als würde Linux von der FSF übernommen.
Sie müssen nur ziemlich allgemeine Betriebssystemfunktionen verwenden, wie man sie in mehreren ähnlichen Kerneln findet.
Ein solcher Treiber, der nicht von Linux-spezifischen Funktionen abhängt, kann nicht als „abgeleitetes Werk“ des Linux-Kernels gelten und kann daher eine beliebige Lizenz wählen.
Umgekehrt ist ein Treiber, der Linux-kernelspezifische Schnittstellen verwendet, die es in anderen Betriebssystemen, nicht einmal in anderen Unix-artigen Kerneln, gibt, per Definition eher ein „Werk auf Basis des Programms“ des Kernels und muss daher in ähnlicher Weise lizenziert werden.
Man muss sich nur den Wortlaut der GPL-2 ansehen, der der Kernel unterliegt.
https://www.gnu.org/licenses/old-licenses/gpl-2.0.html
Die LGPL existiert separat, um getrenntes Linken von freier und proprietärer Software zu erlauben; in der GPL ist das verboten.
Linux steht jedoch unter GPL-2, daher gilt diese zusätzliche Erlaubnis nicht.
Wenn der Nvidia-Treiber nur allgemeine Kernel-APIs verwenden würde, wäre das in Ordnung, aber tatsächlich tut er das nicht.
Weil er versucht, Linux-spezifische APIs, die für Treiber mit GPL-kompatibler Lizenz markiert sind, in nicht-GPL-Form zu verwenden, ist das ein klarer Verstoß gegen die Freie-Software-Lizenz, unter der Linux bereitgestellt wird.
Warum sollte proprietäre Software alle Vorteile freier Software genießen dürfen, ohne irgendwelche Regeln zu befolgen, während freie Software das einfach hinnehmen muss?
Auch demokratische Gesellschaften haben Mechanismen, die Äußerungen bis zu einem gewissen Grad einschränken, um sich selbst zu schützen.
Proprietäre Betriebssysteme gibt es bereits viele, und die kümmern sich überhaupt nicht darum.
Darf es keine Betriebssysteme geben, denen solche Prinzipien wichtig sind? Muss alles ein kaltes, industriefreundliches Werkzeug ohne menschliche Rücksicht sein?
Die Absicht der Lizenz ist, dass alles, was mit dem Kernel gelinkt und in ihn geladen wird, unter einer kompatiblen Copyleft-Lizenz verbreitet wird.
Die Anforderung, dass proprietärer Code keinen GPL-Code „enthalten“ darf, ist die GPL selbst und der zentrale Zweck der GPL.
Allerdings ist umstritten, bis zu welchem Grad allein das Linken gegen eine API eine Verletzung darstellt.
Ein Urteil in beide Richtungen scheint möglich, und eine solche Entscheidung hätte große Auswirkungen auf die GPL.
Da Nvidia-Code in ring0 läuft, gibt es erfahrungsgemäß viel interessantere Tricks, die Nvidia einsetzen könnte, aber im Moment hält man sich damit vermutlich zurück.
Für die Linux-Entwickler gilt dasselbe.
Dieser dumme DRM-Streit hilft niemandem und befeuert nur ein Katz-und-Maus-Spiel, das die Zeit aller verschwendet.
„Leute, kommt miteinander aus.“
Ich verstehe nicht, warum Nvidia so viel Aufwand betreibt, seine Treiber als proprietären Binärklumpen zu behalten.
Software ist nicht der Kern ihrer Verteidigungsfähigkeit, Nvidia ist ein Hardwareunternehmen.
Wenn sie das Kernel-Modul offenlegen würden, hätte das nicht nur keinen Einfluss auf die Hardwareverkäufe, sondern würde auch die Stabilität verbessern und Sympathien bei Entwicklern gewinnen, die sonst absichtlich zu AMD-GPUs greifen.
Denn Kommodifizierung ist das genaue Gegenteil hoher Gewinnmargen.
Bei einem Anteil von rund 80 % am GPU-Markt lassen sich höhere Margen leichter erzielen, indem man die Preise stärker anzieht oder höhere Ebenen des gesamten Stacks kontrolliert.
Zum Beispiel ist es vorteilhaft, wenn die wichtigste Allzweck-GPU-Sprache um die eigene GPU-Architektur herum gebaut ist.
Oder man muss in völlig andere Bereiche expandieren, und dass Nvidia stark in AI einsteigt, liegt auch daran, dass sie ihre GPU-Dominanz nutzen können, um sich dort einen frühen Vorteil zu sichern.
Belege habe ich dafür allerdings nicht.
„Illegal“ ist bis zum Beweis vor Gericht letztlich nur eine Theorie
Worum es hier geht, ist im Grunde DRM im Kernel-Code: Es soll verhindert werden, dass ladbare Kernel-Module erraten können, wo sich Kernel-Datenstrukturen im Speicher befinden
Man weiß, dass Leute versuchen werden, die Grenzen auszureizen, also will man es als Abschreckung so schwer wie möglich machen
Aber man könnte auch argumentieren, dass alle Closed-Source-ladbaren Kernel-Module gleichermaßen gegen die GPL verstoßen, ob mit „Shim“ oder ohne; solche Argumente gab es tatsächlich, aber die meisten haben sie vergessen und benutzen diese DRM-Fiktion als eine Art Ersatz für eine juristische Fiktion
Oder falls die GPL-getaggten Funktionen im Kernel APIs im Sinne von Google gegen Oracle sind, ist die ganze Diskussion womöglich ohnehin nicht besonders bedeutsam
Die meisten ladbaren Kernel-Module befinden sich im Kernel-Source-Tree und werden unter der GPL bereitgestellt
Als nächsten Schritt baut man einfach ein Open-Source-ladbares Modul, das eine kleine virtuelle Maschine enthält, die im User Mode einen binären Blob lädt
Es führt nur binäre Blobs aus, die mit NVIDIAs privatem Schlüssel signiert sind, während der öffentliche Schlüssel im Open-Source-Modul enthalten ist
Oder man baut einen Hypervisor, der Linux virtualisiert und den Großteil des Kernels umgeht, oder …
Wege gibt es immer
Das macht es nur nerviger und erhöht lediglich die Kosten, brauchbare Treiber für Linux zu bekommen, wodurch weniger Aufwand in diese Richtung fließen wird
Ob das ein großer Verlust ist, ist nicht klar
Ich hoffe, dass dieser Streit am Ende nicht dazu führt, dass es keine Nvidia-Treiber für Linux mehr gibt oder sie schlechter werden
Ohne diese Treiber wird mein Lieblingsbetriebssystem wegen Gaming und KI plötzlich weniger nützlich
Vor 10 Jahren war das anders
Damals interessierten sich vor allem ein paar Linux-Nerds dafür, die unter Linux spielen wollten, und sie machten nur einen kleinen Teil des Umsatzes aus
Heute baut praktisch die gesamte Unternehmensbewertung von NVIDIA auf KI auf, und fast alle großen Akteure, die diese Hardware in großen Mengen kaufen, nutzen sie unter Linux
Linux aufzugeben ist für NVIDIA keine Option
Wahrscheinlich werden sie alles tun, damit das nicht passiert
Jegliche Unterstützung entfernen, bis nVidia alles offenlegt
Aber heutzutage haben nicht wir, sondern kommerzielle Unternehmen mehr Einfluss darauf, wie Hardware unter Linux genutzt und unterstützt wird
Nvidia hat den Treiber oder Teile davon als Open Source veröffentlicht und stellt inzwischen auch weiterverteilbare Firmware-Binaries bereit
Außerdem wurde bei einigen älteren Karten die Firmware-Authentifizierung geknackt
Daher hoffe ich, dass die Bedeutung proprietärer Treiber mit der Zeit abnimmt
Auf Kernel-Ebene läuft es also auf „Welche Farbe haben deine Bits?“[1] hinaus … nett?
[1] https://ansuz.sooke.bc.ca/entry/23