Für die Zukunft gerüstet – Linux-Kernel 3.0

Speicherschutz

In dieselbe Kerbe schlägt der Speicherschutz, eine weitere Aufgabe des Memory-Managements. Applikationen dürfen nicht auf die Speicherbereiche einer anderen Applikation oder auf die des Kernels zugreifen und mal eben die im Hauptspeicher abgelegten Passwörter auslesen. Zur Realisierung von Speicherschutz benutzt Linux die in Hardware festgelegten Mechanismen.

Das gilt auch für den Schutz vor Ausführung von Code auf dem Stack (Data Execution Prevention, DEP) – ebenfalls eine wesentliche Eigenschaft zum Schutz vor Hackerangriffen. Unglücklicherweise aktivieren die Linux-Distributoren in ihren 32-Bit-Versionen dieses Feature des Kernels meist nicht.

Abbildung 5: Kernel-Programmierer müssen das Unterbrechungsmodell kennen, um kritische Abschnitte erkennen und richtig schützen zu können.

Die Speicherverwaltung hat noch mehr Aufgaben: Dank Swapping macht sich ein Applikationsprogrammierer keine Gedanken über die Menge des physisch zur Verfügung stehenden Hauptspeichers. Und sollten auf einem 32-Bit-System mehr als die adressierbaren 4 GByte zur Verfügung stehen, ist dank Memory Management auch dieser erweiterte Speicher nutzbar.

Unterbrechungsmodell

Linux unterscheidet vier Ebenen, auf denen es Code abarbeitet (Abbildung 5): Die Userebene ist dem so genannten Userland und damit Applikationen vorbehalten. Die hier laufenden Tasks können unterbrochen (preempted) werden und sich schlafen legen. Auf Multicore-Maschinen allerdings können die Funktionen real mehrfach parallel arbeiten.

Auf der Kernelebene sind Systemcalls und Kernelthreads angesiedelt, die ähnliche Eigenschaften haben: Sie sind unterbrechbar, laufen dadurch auf Singlecore-Maschinen scheinbar parallel, auf Multicore-Maschinen real parallel und sie können schlafen.

Wenn Schlafen verboten ist

Auf der Soft-IRQ-Ebene ist Schlafen dagegen ein absolutes Tabu. Hier arbeiten Timer und Tasklets, also kurze Codesequenzen, die eine Unterbrechung durch Interrupts zulassen und früher auch "Bottom Half" genannt wurden. Auf der untersten Ebene schließlich laufen Interrupt-Serviceroutinen (ISRs). Sie können alle darüber liegenden Codesequenzen unterbrechen. Selbst sind sie typischerweise nicht unterbrechbar (Interrupts gesperrt), es sei denn, sie erlauben dies explizit.

Das Unterbrechungsmodell zeigt nicht nur, dass die jeweils niedrigeren Ebenen darüber liegende Ebenen unterbrechen können, sondern auch, in welchem Kontext eine Ebene abgearbeitet wird. ISRs und Soft-IRQs laufen demnach im Interruptkontext.

Auf Kernelebene wird der Prozesskontext vom Kernelkontext unterschieden. Im Prozesskontext laufen all jene Jobs, die zu einer Userland-Applikation gehören. Das sind die Systemcalls, die die Applikationen aufgerufen haben wie etwa »open()« , »close()« , »read()« oder »write()« . Diese Codesequenzen können Daten zwischen dem Kernel und der zugehörigen Applikation austauschen.

Für den Kernelkontext bleiben nur die Kernelthreads übrig. Für jeden Kontext gibt es in den Kernel-Headerdateien ein Define (»GFP_ATOMIC« für den Interruptkontext, »GFP_KERNEL« für den Kernelkontext und »GFP_USER« für den Prozesskontext). Allgemeine Funktionen, beispielsweise »kmalloc()« (»malloc()« im Kernel), lassen sich aus unterschiedlichen Kontexten aufrufen. Ihnen muss der Kernelprogrammierer über das Define den aktuellen Kontext mitgeben, etwa damit die Funktion weiß, ob sie schlafen darf oder nicht.

Darüber hinaus setzt Linux auf typisierte Objekte und nutzt mit dem Slab-Allocator die Vorteile der Wiederverwertung [3]. Hierbei stellt der Kernel eine Reihe bereits vorinitialisierter Objekte zur Verfügung. Das hat vor allem Performance-Vorteile: Das gleichzeitige Initialisieren mehrerer gleichartiger Objekte nutzt den Hauptspeicher und die Wirkung des Prozessor-Cache besser aus.

Zudem fällt Code weg, weil sich die Operationen "Speicher allozieren", "Objekt vorinitialisieren", "Objekt deinitialisieren" und "Speicher freigeben" einsparen lassen (Abbildung 4). Der Sysadmin bekommt Informationen zu den Objekten, indem er das Kommando »cat /proc/slabinfo« aufruft.

Virtual Filesystem Switch

Das I/O-Management ist für den Zugriff auf Dateien und auf Peripherie zuständig. Zentrale Verteilstation ist hierfür der Virtual Filesystem Switch (VFS). Dieser verteilt die Zugriffe auf zeichen- oder blockorientierte Geräte, setzt Dateinamen auf Sektornummern um, speichert die Daten zwischen und gibt Aufträge für die Festplatten an den I/O-Scheduler weiter. Der I/O-Scheduler ist für eine geschickte Sortierung zuständig, sodass der Lesekopf einer Festplatte möglichst wenige Rückwärtsbewegungen macht. Da Solid State Disks (Flashspeicher) keine Köpfe zu bewegen haben, reicht Linux in diesem Szenario bei entsprechender Konfiguration die Daten direkt an die Platte weiter.

Der VFS implementiert auch das hierarchische Modell, gemäß dem Linux Daten auf Festplatten abspeichert oder wieder einliest. Jede Datei ist in diesem Modell über einen Inode repräsentiert [4]. Der Inode, der über eine eindeutige Inodenummer bestimmt ist, speichert die wesentlichen Meta-Informationen: Dateigröße, Zeitstempel bezüglich des Anlegens, des letzten Zugriffs oder der letzten Modifikation, Zugriffsrechte, Besitzverhältnisse und so weiter. Ein einzelner Name gehört allerdings nicht zu diesen Meta-Informationen. Inodenummern lassen sich im Übrigen durch Eingabe von »ls -i« in einer Konsole listen.

Ein Dentry genanntes Objekt verknüpft schließlich einen Dateinamen mit dem Inode. Um per Namen auf eine Datei zugreifen zu können, sind zunächst die Dentries zu durchsuchen. Diesen zeitlich teuren Vorgang beschleunigt Linux durch einen Zwischenspeicher, den Dcache.

Mit dem Inode-Objekt ist eine Reihe von Methoden verknüpft, die – verkürzt ausgedrückt – die Abbildung auf die Festplatte und die dort vorhandenen Datenstrukturen, das eigentlichen Dateisystem, vornehmen.