claim.gif
Linux Magazin Linux User Easy Linux Ubuntu User International Linux Community
Erschienen in EasyLinux 06/2006

Linux und proprietäre Treibermodule

Linux zwischen Funktionalität und Freiheit

von Carsten Schnober


Linux und Hardware -- eine Hassliebe. Viele Hersteller kümmern sich gar nicht um das freie Betriebssystem, andere halten die Quellen selbst geschriebener Treiber zurück. Linux-Entwickler fürchten um die Freiheit der Software, ab Version 10.1 kommt auch Suse nicht mehr mit unfreien Gerätetreibern.

Besitzern von ISDN-Karten der Firma AVM sträubten sich vielfach die Nackenhaare, als sie die Nachricht hörten: Suse Linux 10.1 enthält die Gerätetreiber nicht mehr. Und nicht nur sie fliegen raus, sondern auch alle anderen Treiber, die keine freie Software sind -- darunter auch die Grafikkartentreiber von NVidia und ATI.

Sture Hersteller

Die Hardware-Unterstützung gilt als eine Schwachstelle von Linux. Die meisten Hersteller ignorieren die Benutzer des freien Betriebssystems schlicht und liefern ausschließlich Windows-Treiber aus. Viele Geräte funktionieren dennoch, denn oft lassen sie sich über standardisierte Verfahren ansteuern: beispielsweise Festplatten, CD- und DVD-Laufwerke und -Brenner, die meisten USB-Speicher-Sticks sowie Tastaturen und Mäuse.

Dank solcher Standards konnten die Linux-Entwickler viele Hardware-Treiber selbst entwickeln, und das ist auch der Grund, aus dem Linux auf fast allen PCs läuft -- auch wenn es manchmal nicht alle Funktionen unterstützt. Schwerwiegende Probleme gibt es lediglich dann, wenn sich Hersteller beispielsweise ein eigenes Verfahren ausgedacht haben, um Basis-Hardware anzusteuern, und dafür nur Windows-Treiber ausliefern. Linux hat keine Chance, gängigen Standards zuwiderlaufende Geräte zu unterstützen.

Leider gibt es nicht in allen Hardware-Kategorien vergleichbare Standards. So braucht beispielsweise jeder Scanner einen eigenen Treiber. Für Drucker existiert die Sprache Postscript, die jedoch die meisten billigen Geräte nicht verstehen. Postscript-Drucker funktionieren unter Linux tadellos, aber die anderen sprechen ihre jeweils eigenen Dialekte und benötigen deshalb wiederum eigene Treiber. Manche Hersteller stellen diese für Linux bereit, manche unterstützen freie Programmierer bei der Entwicklung, und einige Drucker funktionieren unter Linux gar nicht.

Drucker und Scanner haben immerhin den Vorteil, dass sie einheitliche Anschlüsse verwenden: inzwischen gewöhnlich USB, ältere Modelle auch den Parallel-Port. Das Betriebssystem stellt eine grundlegende Kommunikationsebene bereit, indem es einen Treiber für die USB-Hardware lädt. Danach verständigt sich dann die Druckerverwaltung des Desktops mit dem Drucker, der eigentliche Betriebssystem-Kernel braucht sich darum nicht weiter zu kümmern. Technisch äußert sich das darin, dass Linux nur den Treiber für den USB-Controller in Form eines Kernel-Moduls laden muss; der Druckertreiber fällt nicht in die Zuständigkeit des Kernels, sondern in die der Drucker-Software.

Jedes moderne Betriebssystem basiert auf einem Kernel, der beim Hochfahren als Erstes geladen wird und dafür sorgt, dass weitere Programme überhaupt starten können. Der Linux-Kernel lässt sich im laufenden Betrieb mit Kernel-Modulen um zusätzliche Funktionalität, beispielsweise Hardware-Treiber, erweitern. Auf diese Weise bleibt er klein und unbelastet von Treibern, die das System aktuell nicht benötigt.

Module und Treiber

Abhängig von der Hardware unterscheidet sich unter Linux die Art der Treiber. Kernel-Module kommen nur dann zum Einsatz, wenn ein direkter Zugriff auf die Hardware notwendig ist. Das trifft wie beschrieben beispielsweise auf USB-Anschlüsse zu, ebenso verhält es sich bei eingebauten Geräten wie Grafikkarten sowie bei internen ISDN-Karten und Modems. Bei einem externen Modem steuert ein Kernel-Modul ebenfalls nur den Anschluss an -- den USB- oder den seriellen Port. Um die eigentliche Kommunikation mit dem Gerät kümmert sich wiederum ein Anwendungsprogramm, beispielsweise KInternet oder KPPP (Abbildung 1) für die Internet-Einwahl.

Abb. 1: Ob ein Gerät über ein Kernel-Modul oder eine Anwendung angesteuert wird, hängt von der Hardware-Kategorie ab. Eingebaute Hardware benötigt in der Regel ein Kernel-Modul; um über standardisierte Anschlüsse angebundene Geräte kümmern sich Anwendungen wie KPPP.

Novell hat mit der Ankündigung, ab Suse Linux 10.1 keine unfreien -- proprietären -- Kernel-Module mehr zu unterstützen, die in Linux-Entwicklerkreisen andauernde Diskussion über den Umgang mit den Treibern externer Anbieter zu den Endanwendern getragen. Unter anderem die Grafikkarten der größten Hersteller NVidia und ATI, ISDN-Karten von AVM sowie viele Webcams und WLAN-Karten setzen zum Funktionieren unter Linux Kernel-Module voraus, welche die Hersteller selbst entwickeln und anbieten. Sie stellen diese den Linux-Anwendern kostenlos zur Verfügung, behalten aber den Programmcode für sich.

Darin liegt ein entscheidender Unterschied zwischen freier und kostenloser Software: Bei freier Software wie dem Linux-Betriebssystem haben alle Interessierten das Recht, sie an ihre Bedürfnisse anzupassen, wozu sie Zugriff auf den Programmcode benötigen. Proprietäre Software kann ebenfalls gratis vorliegen, aber ohne veröffentlichten Quellcode.

Die Lizenz, unter der auch der Linux-Kernel steht, die GPL (General Public License) [1], schreibt vor, dass aus GPL-Programmen abgeleitete Software ebenfalls unter der GPL veröffentlicht werden muss. Im Falle von Kernel-Modulen ist jedoch fraglich, ob sie als eigenständige Programme oder als Teile des Linux-Kernels anzusehen sind. Bei gewöhnlicher Anwender-Software für Linux stellt sich diese Frage nicht, weil sie zwar unter Linux läuft, jedoch eindeutig nicht davon abgeleitet ist. Kernel-Module dagegen werden aus Sicht einiger Entwickler zu einem Bestandteil des GPL-lizenzierten Betriebssystems, sobald der Kernel sie lädt.

Die rechtliche Frage steht allerdings eher im Hintergrund, größere Bedenken haben viele Linux-Entwickler aus technischen Gründen. Sie sehen Binärmodule als Unwägbarkeit, da Kernel-Module im Gegensatz zu reiner Anwender-Software durch die Möglichkeit des direkten Zugriffs auf die Hardware des Computers einen privilegierten Status haben. Ein fehlerhaftes Kernel-Modul kann deshalb das gesamte System destabilisieren, während ein Desktop-Programm auch bei einem Absturz den Kernel nicht in Mitleidenschaft zieht.


Binärmodule: Kernel-Module externer Hersteller, die ausschließlich in einer maschinell lesbaren Form vorliegen. Von freier Software, auch dem Linux-Kernel und den dazugehörigen Modulen, gibt es darüber hinaus den für Menschen lesbare Quelltext.

Teufelskreis

Die Kernel-Entwickler können ohne Zugriff auf den Quelltext eines Moduls nicht nachvollziehen, ob es für ein instabiles System verantwortlich zeichnet, und gegebenenfalls Fehler korrigieren. Stattdessen müssen sie sich darauf verlassen, dass der Hersteller selbst Hand anlegt -- ein konkretes Beispiel, in dem das nicht funktioniert, dokumentiert der Webcam-Test in diesem Heft. Wie bei gewöhnlicher proprietärer Software auch, muss der Hersteller mit dieser Aufgabe aber bezahlte Programmierer beauftragen und zuvor abwägen, ob sich die Investition lohnt.

Im schlechten Fall entscheidet sich ein Hardware-Produzent gegen die Fehlersuche, und Benutzer des betreffenden Kernel-Moduls müssen ein instabiles System in Kauf nehmen. Bisher gibt es nur wenige verbreitete Binärmodule, die gewöhnlich ohne größere bekannte Fehler funktionieren. Die Gefahr besteht jedoch immer, denn Binärmodule hebeln generell einen Hauptvorteil des quelloffenen Software-Entwicklungsmodells aus.

Firmen, die proprietäre Linux-Treiber für ihre Hardware bereitstellen, argumentieren, dass Konkurrenten über den Quelltext ihrer Kernel-Module Details über das Gerätedesign erfahren und Techniken für ihre eigene Hardware kopieren könnten. Sie fordern deshalb eine über die Kernel-Versionen hinweg unveränderliche Schnittstelle, über die Module von Drittanbietern mit Linux kommunizieren können. Bisher verändert sich diese Schnittstelle immer wieder, und jedes Mal müssen die Anbieter ihre Module an den Kernel anpassen -- ein Zeit- und damit verbunden ein Kostenfaktor.

Auch hier vertreten viele Linux-Programmierer einen gegenläufigen Standpunkt. Sie möchten nicht, dass Entwickler einzelner Module das Kernel-Design beeinflussen. Schließlich verändern sie diesen nicht als Selbstzweck, sondern um ihn zu optimieren und um Fehler auszuräumen. Stattdessen sehen sie die Weigerung der Hersteller, den Programmcode ihrer Kernel-Module zu veröffentlichen, als das eigentliche Problem.

Der ehemals bei Red Hat angestellte Kernel-Entwickler Arjan van de Ven skizziert in seinem Text "Linux in einer binären Welt... ein Untergangsszenario" [2] einen Teufelskreis, in den Linux geraten könnte, wenn die Binärmodule an Akzeptanz gewinnen. Er fürchtet, dass immer mehr Hardware-Hersteller Kernel-Module veröffentlichen, ohne den Quelltext dazu herauszugeben, um sich gegenüber der ebenso verfahrenden Konkurrenz keine Blöße zu geben.

Freie Software unter Druck

Mit der zunehmenden Verbreitung von Binärmodulen sieht das Untergangsszenario vor, dass Linux-Desktops kaum noch ohne diese auskommen. Weil es keine dauerhaft standardisierte Schnittstelle zum Kernel gibt, stellen die Hersteller ihre Treiber ausschließlich für die von den großen Linux-Distributionen wie Red Hat oder Suse eingesetzten Kernel-Versionen bereit, für andere Linux-Versionen wird die jeweilige Hardware unbenutzbar.

Um wieder eine einheitliche Basis bereitzustellen, sieht sich die Linux-Gemeinde im Katastrophenszenario daraufhin gezwungen, dem Druck der Hersteller nachzugeben und einheitliche Schnittstellen bereitzustellen. Dann läuft die durch Binärmodule unterstützte Hardware wieder unabhängig von der Linux-Distribution.

Eines Tages könnte sich zeigen, dass ein schwerwiegender Sicherheitsfehler in der festgelegten Kernel-Schnittstelle vorliegt, und die Linux-Entwickler müssen sie ändern, wollen sie das System nicht Viren, Würmern oder anderen Gefahren aussetzen. Das zwingt die Hersteller wieder, ihre Treiber an die neue Umgebung anzupassen. Möglicherweise ist bis zu diesem Zeitpunkt aber schon viel Zeit verstrichen, beteiligte Firmen existieren nicht mehr oder möchten Linux-Treiber für Produkte nicht mehr anpassen, weil sie diese vielleicht nicht mehr verkaufen und kein Geld mehr aufwenden wollen.

Besitzer von Hardware ohne aktualisierte Treiber stehen dann vor den beiden unzufriedenstellenden Alternativen, weiterhin ein unsicheres System zu verwenden oder sich neue, mitunter teure Geräte zu kaufen.

Kompromiss gesucht

Bislang gibt es nur wenige Hersteller, die überhaupt Linux-Treiber für ihre Geräte anbieten, deshalb handelt es sich bei den meisten Modulen um feste Bestandteile des Kernels und somit um freie Software. Etabliert haben sich vor allem die Binärmodule für die Grafikkarten von NVidia und ATI. Einige Distributionen haben sich damit arrangiert und liefern die Treiber entweder direkt auf ihren Datenträgern aus oder stellen Pakete bereit, die Download und Installation automatisieren (Abbildung 2), denn die Grafikkarte stellt eine zentrale Komponente jedes PCs dar. Ohne die herstellereigenen Module kann der Besitzer meist nur die Basisfunktionen nutzen -- 3D-Anwendungen und -Spiele gehören nicht dazu.

Abb. 2: Proprietäre Treiber liefern viele Distributoren nicht auf ihren Datenträgern aus, sondern stellen Pakete bereit, die den Download vom Hersteller und die Installation vereinfachen.

Der Suse-Linux-Hersteller Novell hat sich nun auf die Seite der Binärmodulgegner geschlagen und liefert ab der Suse-Version 10.1 keine proprietären Module mehr aus. Sie lassen sich natürlich nach wie vor direkt von der Homepage des jeweiligen Herstellers herunterladen und installieren, für dabei auftretende Schwierigkeiten möchte Novell jedoch keine Verantwortung übernehmen.

Das sehen einige Benutzer als Einschränkung im Service. Die Befürchtungen vieler Linux-Entwickler sind aber nicht unbegründet. Obwohl es nicht so schlimm kommen muss wie im Untergangsszenario beschrieben, liegt es letztlich auch im Interesse der Endanwender, von möglichst wenigen proprietären Treibern abhängig zu sein. (csc)

Infos
[1] Die General Public License: http://www.gnu.de/gpl-ger.html
[2] Linux in a binary world... a doomsday scenario: http://marc.theaimsgroup.com/?l=linux-kernel&m=113378006232564&w=2

Dieser Online-Artikel kann Links enthalten, die auf nicht mehr vorhandene Seiten verweisen. Wir ändern solche "broken links" nur in wenigen Ausnahmefällen. Der Online-Artikel soll möglichst unverändert der gedruckten Fassung entsprechen.

Druckerfreundliche Version | Feedback zu dieser Seite | Datenschutz | © 2021 COMPUTEC MEDIA GmbH | Last modified: 2008-11-05 16:56

[Linux-Magazin] [LinuxUser] [Linux-Community]