Kernelmodule laden und entladen ist einfach. Wer aber weiß, was dabei passiert, erkennt Möglichkeiten, die weit über Treiber hinausgehen. Selbst das Schreiben eigener Module ist dann keine Hexerei mehr.
Kernelmodule sind für Entwickler und Anwender gleichermaßen eine gute Idee: Die Komponenten sind klein, überschaubar und die Entwickler können bequem außerhalb des Kerneltrees Treiber entwickeln, der Anwender lädt nur die Bestandteile, die er wirklich braucht. Kernelmodule sind auch einfach zu benutzen: »insmod modul.o« - schon ist ein Treiber für ein Dateisystem oder ein Stückchen Hardware geladen. Was steckt hinter dieser scheinbar so einfachen Verwendbarkeit und wie funktioniert so ein Modul genau?
Kernelmodule programmiert man, um Treiber für Hardware, spezielle Filesysteme oder Netzwerkprokolle zu entwickeln. Lange Zeit war beispielsweise die Funktionalität von IPv6 in zwei unterschiedlichen Implementierungen erhältlich - eine im Kernel und die andere extern. Die meisten Anwender wissen, dass sie Treiber als Module laden können, weniger bekannt ist die Möglichkeit, eigene Implementationen von Systemcalls als Module zu entwickeln. Man kann neue Systemcalls schreiben und als Kernelmodul laden oder bereits vorhandene Linux-Systemcalls neu programmieren. Lädt man diese als Modul, überschreiben die neuen Systemcalls die vorhandenen Originale; ist das Modul entladen, werden die ursprünglichen Systemcalls wieder sichtbar.
Manche Module enthalten Treiber für spezifische Executables, um beispielsweise Java-Bytecode direkt ausführen zu können: Dank des entsprechenden Moduls genügt dann ein Aufruf von » meinprogramm« statt »java meinprogramm«. Mit dem Modul »binfmt_java« lädt der Kernel einen Bytecode-Interpreter und behandelt Java-Bytecode wie ELF- oder das alte A.out-Format.
Es gibt sogar einen Mechanismus, in den Modulen des Linux-Kernels die Abhängigkeiten der Lizenz festlegen: Der Entwickler kann bestimmte Funktionen einarbeiten, damit sich nur Module, die ebenfalls unter der GPL veröffentlicht werden, von einem GPL-Modul abhängig machen.
Viele spezielle Bedürfnisse wie Krypto-Ergänzungen und Ähnliches sind überhaupt nur mit Modulen außerhalb des Kernelbaums abzudecken: Unter der Adresse [http://loop-aes.sourceforge.net/] findet man beispielsweise die Sourcen, um ein Loopback-Device mit AES zu verschlüsseln. Verschiedene Gründe sprechen dafür, Kryptographie in einem externen Modul zu verwenden: Internationale Kryptographiegesetze, Exportregelungen oder Softwarepatente zwingen Entwickler und Distributoren immer wieder dazu, zwischen einheimischen und internationalen Versionen zu unterscheiden.
Abbildung 1: Typische Lsmod-Ausgabe. Auch Abhängigkeiten zwischen Modulen werden angezeigt.
Reine Praxiserwägungen spielen ebenfalls eine Rolle: Um ein Linux-System zu betreiben, ist ein verschlüsseltes Loopback-Device keine Grundvoraussetzung und viele Anwender werden so spezielle Anwendungen nie benötigen. Externe Module verhindern außerdem, dass der Kerneltree ins Uferlose wächst und jedes Sonder-Spezial-Feature gleich im Hauptbaum landet.
Alle Rezensionen aus dem Linux-Magazin
Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...
