Architektur-Überblick

Zwei Welten: Benutzermodus und Kernelmodus

Damit der Kernel Programme voneinander und vor sich selbst schützen kann, braucht er Hilfe von der Hardware. Jede moderne CPU kennt mindestens zwei Betriebsarten:

• Im KernelmodusKernelmodusPrivilegierter Betriebsmodus der CPU, in dem alle Befehle und der gesamte Speicher zugänglich sind. Auf x86 Ring 0. sind alle Befehle erlaubt und der gesamte Speicher ist zugänglich.
• Im BenutzermodusBenutzermodusEingeschränkter Betriebsmodus der CPU für Anwendungen. Privilegierte Befehle lösen eine Ausnahme aus. Auf x86 Ring 3. sind privilegierte Befehle gesperrt, und nur die für den Benutzermodus freigegebenen Speicherseiten sind erreichbar.

Auf ARM64 heißen die Privilegstufen Exception Levels: Anwendungen laufen in EL0, der Kernel in EL1, ein Hypervisor in EL2 und Firmware in EL3. RISC-V unterscheidet entsprechend User, Supervisor und Machine Mode.

Privilegiert sind alle Befehle, mit denen sich die Schutzmechanismen aushebeln ließen, zum Beispiel:

• cli/sti: Interrupts sperren und freigeben, sonst könnte ein Programm den Scheduler blockieren,
• mov nach CR3: auf andere Seitentabellen umschalten, also in fremde Adressräume wechseln,
• wrmsr: modellspezifische Register beschreiben, etwa die Einsprungadresse für Systemaufrufe,
• hlt: den Prozessor anhalten.

Versucht ein Programm im Benutzermodus einen solchen Befehl, löst die CPU eine Ausnahme aus (auf x86 eine General Protection Fault). Der Kernel übernimmt und beendet das Programm in der Regel mit dem Signal SIGSEGV.

Speicherschutz über Seitentabellen

Der zweite Baustein ist die MMUMMU (Memory Management Unit)Hardware-Baustein der CPU, der virtuelle in physische Adressen übersetzt und dabei Zugriffsrechte prüft.. Jeder Eintrag in den Seitentabellen enthält neben der physischen Adresse einige Bits mit Zugriffsrechten, darunter das User/Supervisor-Bit. Seiten des Kernels sind als „nur Supervisor“ markiert. Greift Code im Benutzermodus darauf zu, meldet die MMU einen Seitenfehler, und der Zugriff scheitert, obwohl die Seite im Adressraum eingeblendet ist.

Der virtuelle Adressraum

Jeder Prozess sieht einen eigenen virtuellen Adressraum. Die MMU übersetzt jede Adresse anhand der Seitentabellen des Prozesses in eine physische Adresse. Wie das genau funktioniert, behandelt Kapitel 7. Hier interessiert zunächst die grobe Aufteilung:

• Die untere Hälfte (User Space) ist für jeden Prozess anders. Dort liegen Programmcode, Daten, Heap, eingeblendete Bibliotheken und der Stack.
• Die obere Hälfte (Kernel Space) ist in allen Prozessen gleich eingeblendet. Deshalb muss der Kernel bei einem Systemaufruf nicht den Adressraum wechseln und kann direkt auf den Puffer des aufrufenden Prozesses zugreifen, solange PTI nicht aktiv ist.
• Ein Teil des Kernel-Adressraums bildet den gesamten physischen Arbeitsspeicher linear ab (direct map). So erreicht der Kernel jede physische Seite über eine einfache Adressrechnung.

Drei Wege in den Kernel

Der Kernel ist kein Prozess, der ständig nebenher läuft. Er wird aktiv, wenn etwas passiert: Die CPU unterbricht den laufenden Code und springt an eine vom Kernel festgelegte Adresse. Dafür gibt es genau drei Anlässe:

Nicht jede AusnahmeAusnahme (Exception)Von der CPU selbst ausgelöste Unterbrechung als Folge des gerade ausgeführten Befehls, etwa ein Seitenfehler oder eine Division durch null. ist ein Fehler. Ein Seitenfehler ist meist völlig normal: Er zeigt dem Kernel, dass eine Seite erst jetzt tatsächlich gebraucht wird, etwa weil sie noch von der Festplatte geladen oder erstmals mit Speicher hinterlegt werden muss. Dieses „verzögerte“ Bereitstellen von Speicher (demand paging) ist ein zentrales Prinzip der Speicherverwaltung.

Prozesskontext und Interruptkontext

Für die Kernel-Programmierung ist entscheidend, in wessen Auftrag Kernel-Code gerade läuft:

• Im Prozesskontext arbeitet der Kernel für einen bestimmten Task, etwa während eines Systemaufrufs. Das Makro current zeigt auf dessen task_struct. Der Code darf schlafen, also blockieren und warten, zum Beispiel auf Daten von der Festplatte.
• Im Interruptkontext reagiert der Kernel auf ein Hardware-Ereignis. Der unterbrochene Prozess hat damit nichts zu tun. Hier darf der Code niemals schlafen, denn es gibt keinen Task, den der Scheduler stattdessen schlafen legen könnte.

Die Subsysteme des Kernels

Intern ist der Kernel in Subsysteme gegliedert, die jeweils einen klar umrissenen Aufgabenbereich haben und meist einem eigenen Verzeichnis im Quellcode entsprechen. Jedes Subsystem hat eigene Maintainer, die Änderungen prüfen und an Linus Torvalds weiterreichen.

Zusammenspiel am Beispiel: cat notizen.txt

Ein einfacher Befehl in der Shell zeigt, wie eng die Subsysteme zusammenarbeiten:

1. Prozessverwaltung: Die Shell erzeugt mit fork() (genauer clone()) einen neuen Prozess, der mit execve() das Programm /usr/bin/cat lädt (Kapitel 5).
2. Speicherverwaltung: execve() baut einen neuen Adressraum auf. Programmcode und Bibliotheken werden nur eingeblendet. Erst beim ersten Zugriff lösen Seitenfehler das tatsächliche Laden aus.
3. VFS: cat ruft openat() auf. Das VFS zerlegt den Pfad, findet die Datei im zuständigen Dateisystem (etwa ext4) und prüft die Zugriffsrechte, zusätzlich auch über die LSM-Hooks.
4. Page Cache: Bei read() schaut der Kernel zuerst im Page CachePage CacheTeil des Arbeitsspeichers, in dem der Kernel Dateiinhalte zwischenspeichert, um Zugriffe auf Datenträger zu vermeiden. nach. Liegt die Datei schon im RAM, ist der Aufruf in Mikrosekunden erledigt.
5. Block-Schicht und Treiber: Andernfalls erzeugt das Dateisystem eine I/O-Anfrage. Die Block-Schicht reicht sie an den NVMe-Treiber weiter, und der Prozess schläft.
6. Interrupt und Scheduler: Sind die Daten da, meldet die SSD dies per Interrupt. Der Kernel markiert den Prozess als lauffähig, und der Scheduler lässt ihn wieder rechnen.
7. Ausgabe: cat schreibt mit write() auf die Standardausgabe. Das geht über das Terminal-Subsystem (TTY) an das Terminalprogramm.

Dieser Ablauf berührt fast jedes Subsystem. Die folgenden Kapitel nehmen sie einzeln unter die Lupe.

Monolithisch, aber modular: Kernel-Module

Viele Teile des Kernels lassen sich wahlweise fest einbauen oder als ladbares ModulKernel-ModulZur Laufzeit ladbarer Teil des Kernels (Datei mit Endung .ko), meist ein Gerätetreiber oder Dateisystem. (.ko-Datei) übersetzen. Das legt die Kernel-Konfiguration fest: y für fest eingebaut, m für Modul, n für gar nicht. Distributionen bauen die meisten Treiber als Module, damit derselbe Kernel auf sehr unterschiedlicher Hardware läuft, ohne alle Treiber im Speicher zu halten.

Ein minimales Modul sieht so aus:

#include <linux/init.h>
#include <linux/module.h>

static int __init hello_init(void)
{
	pr_info("Hallo, Kernel!\n");
	return 0;            /* 0 = erfolgreich geladen */
}

static void __exit hello_exit(void)
{
	pr_info("Tschüss, Kernel!\n");
}

module_init(hello_init);
module_exit(hello_exit);

MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Minimales Beispielmodul");

Geladen wird ein Modul mit modprobe, das auch Abhängigkeiten zu anderen Modulen auflöst. pr_info() schreibt in den Kernel-Log, den dmesg anzeigt. Wie man ein solches Modul übersetzt, zeigt Kapitel 17.

Kernel-Threads

Nicht alle Arbeit im Kernel geschieht im Auftrag eines Benutzerprogramms. Für Hintergrundaufgaben startet der Kernel eigene Kernel-ThreadsKernel-ThreadTask, der ausschließlich im Kernelmodus läuft und keinen eigenen User-Space-Adressraum hat. In ps erscheint er in eckigen Klammern, z. B. [kworker/0:1].. Sie laufen ausschließlich im Kernelmodus und haben keinen eigenen User-Space-Adressraum. Einige Beispiele:

Ein Blick in den Quellbaum

Die Gliederung in Subsysteme spiegelt sich direkt in der Verzeichnisstruktur des Quellcodes wider:

Besonderheiten der Kernel-Programmierung

Kernel-Code ist C (seit Linux 5.18 im Standard GNU C11) und zunehmend auch Rust. Er unterscheidet sich aber deutlich von gewöhnlicher Anwendungsprogrammierung:

• Keine C-Standardbibliothek. Es gibt kein printf() und kein malloc(). Der Kernel bringt eigene Gegenstücke mit, etwa printk()/pr_info() und kmalloc().
• Kleiner, fester Stack. Jeder Task hat im Kernel nur einen kleinen Stack (auf x86-64 16 KiB). Große lokale Arrays und tiefe Rekursion verbieten sich.
• Keine Gleitkommazahlen. Der Kernel sichert die FPU-Register bei Systemaufrufen nicht automatisch. Gleitkomma-Arithmetik ist deshalb nur in speziell geschützten Abschnitten erlaubt.
• Kein Speicherschutz vor sich selbst. Ein ungültiger Zeigerzugriff führt nicht zu einem sauberen Programmabbruch, sondern zu einem Oops oder einer Kernel Panic.
• Nebenläufigkeit überall. Auf mehreren CPUs gleichzeitig, unterbrochen von Interrupts und verdrängt vom Scheduler: Fast jede gemeinsam genutzte Datenstruktur braucht Synchronisation (Kapitel 9).

# Adressraum der eigenen Shell: Programmcode, Heap, Bibliotheken, Stack, vDSO
cat /proc/$$/maps

# Kernel-Threads: alle Kinder von kthreadd (PID 2)
ps -o pid,ppid,comm --ppid 2 | head -n 20

# Wie oft wurde welcher Interrupt auf welcher CPU ausgelöst?
head -n 15 /proc/interrupts

# Informationen zu einem Modul
modinfo ext4 | head -n 10