Was ist der Linux-Kernel?

Wenn du Linux eine Weile benutzt, läuft dir der Begriff Kernel ständig über den Weg. Beim Update wird ein neuer installiert, ein Treiber braucht eine bestimmte Kernel-Version, und nach manchen Aktualisierungen sollst du plötzlich neu starten. Nur: Was ist dieser Kernel eigentlich – und warum hängt so viel an ihm?

Ganz knapp gesagt: Der Kernel ist der Teil von Linux, der zwischen deinen Programmen und der Hardware sitzt. Startest du ein Programm, öffnest eine Datei oder schickst Daten durchs Netzwerk, kommt der Kernel ins Spiel. Er verteilt CPU-Zeit und Speicher, spricht über Treiber mit der Hardware und entscheidet, welcher Prozess worauf zugreifen darf. Ohne ihn läuft nichts. Wirklich nichts.

Dabei ist der Kernel nicht das, was du normalerweise als „Linux“ vor dir siehst. KDE oder GNOME gehören nicht dazu, Bash auch nicht, und selbst systemd läuft außerhalb des Kernels. Ubuntu, Debian oder Fedora sind ebenfalls nicht der Kernel, sondern komplette Distributionen, die ihn zusammen mit dem restlichen Userspace ausliefern.

Genau diese Trennung ist wichtig. Spätestens wenn ein Treiber streikt, nach einem Update noch der alte Kernel läuft oder du verstehen willst, was /proc und /sys eigentlich anzeigen, reicht „Linux ist halt das Betriebssystem“ nicht mehr besonders weit.

Eine laufende Linux-Installation und ein Terminal reichen für die Beispiele. Kein eigener Kernel, und an Modulen wird hier auch nicht zum Spaß geschraubt. Es geht um das, was auf deinem Rechner ohnehin die ganze Zeit arbeitet.

❗ Typische Verwechslung: „Linux“ meint umgangssprachlich oft die komplette Installation. Technisch ist Linux der Kernel. Ubuntu, Fedora oder Debian sind Distributionen: Kernel plus Userspace, Pakete, Init-System und oft ein Desktop.

Kernel, Userspace und Distribution

Was du auf dem Bildschirm siehst, läuft fast nie im Kernel. Editor, Browser, Shell, Webserver: das ist Userspace. Der Kernel sitzt darunter. Er läuft im privilegierten Modus der CPU, darf Hardware direkt ansprechen, Speicher zuweisen und Prozesse unterbrechen. Ein Userspace-Programm darf das nicht. Es bittet über einen Systemaufruf.

Die Shell interpretiert deine Eingabe und startet Programme. Was diese Programme anschließend von Dateien, Speicher, Netzwerk oder Hardware brauchen, läuft über Systemaufrufe zum Kernel.

Was der Kernel ist

Linux verwendet einen Unix-ähnlichen, monolithischen Kernel. Das klingt sperriger, als es ist: Treiber, Dateisysteme, Netzwerkstack und Speicherverwaltung laufen im privilegierten Kernelraum. Viele Teile lassen sich trotzdem als Module nachladen.

Was er konkret macht – und was nicht:

„Monolithisch“ heißt: Diese Teile teilen sich denselben privilegierten Adressraum. Ein Treiber ist kein Mini-Betriebssystem daneben, sondern Kernel-Code. Ein geladenes Modul gehört zum Kernel. Es sitzt nur nicht fest in jeder Installation.

Warum man oft GNU/Linux sagt

Vor allem GNU landet oft im selben Topf wie der Kernel. Das GNU-Projekt liefert seit den 1980er Jahren freie Userspace-Werkzeuge (gcc, coreutils, bash). Viele Desktop- und Server-Distributionen kombinieren genau das mit dem Linux-Kernel. Deshalb spricht man oft von GNU/Linux. Gegenbeispiele gibt es: Android nutzt denselben Kernel mit einem anderen Userspace. BusyBox-Systeme ebenfalls.

💡 Tipp: Wenn jemand „Linux neu installieren“ sagt, meint er fast immer die Distribution. Ein Kernel-Update ist enger: Es tauscht den privilegierten Kern aus und verlangt in der Regel einen Neustart, bevor die neue Version wirklich läuft.

Von Unix zu Linux

Linux ist kein umbenannter Unix-Quellbaum. Die Idee kommt von Unix: ein Mehrbenutzersystem, das Prozesse, Dateien und Geräte über einen Kernel bündelt. Der Code kommt von Linus Torvalds und Tausenden späterer Maintainer. Das ist ein Unterschied, der später bei Lizenzen und Zertifizierungen noch zählt.

1. 1969Bell Labs: Unix entsteht (Thompson, Ritchie)
2. 1977BSD in Berkeley: eigene Unix-Linie
3. 1983System V (AT&T); GNU-Projekt, Kernel fehlt
4. 1987MINIX (Tanenbaum): Lehr-Unix auf dem PC
5. 1991Torvalds: Linux 0.01 / 0.02 auf dem 386
6. 1992GPL-2.0; Kernel und GNU-Tools gemeinsam genutzt

Unix an den Bell Labs

Unix entstand Ende der 1960er in den Bell Laboratories und war im Vergleich zu vielen damaligen Großrechnersystemen deutlich kleiner. Ken Thompson und Dennis Ritchie bauten ein System, das bald in C neu geschrieben wurde. C machte den Kernel portierbar – und genau das unterschied Unix von vielen Betriebssystemen, die an eine Maschine geklebt waren.

Ende der 1970er Jahre entwickelte sich mit BSD (Berkeley Software Distribution) an der University of California eine wichtige Unix-Linie. AT&T bündelte seine kommerzielle Unix-Entwicklung später in System V, das 1983 erschien. Aus System V gingen später Varianten wie Solaris oder HP-UX hervor.

Beide Linien bleiben Kernel plus Userspace als ein Betriebssystem. Der Quellcode war lange proprietär oder nur unter engen Lizenzen zugänglich. Wer Unix auf einem PC haben wollte, kaufte in den 1980ern teure Lizenzen oder begnügte sich mit Lehrsystemen.

GNU, MINIX und die Lücke auf dem PC

1983 kündigte Richard Stallman das GNU-Projekt an: ein vollständig freies Unix-artiges System. Compiler, Editoren und Basiswerkzeuge entstanden. Der eigene Kernel, GNU Hurd, wurde ein Microkernel-Projekt und kam lange nicht in den Alltag.

1987 veröffentlichte Andrew S. Tanenbaum MINIX, ein Unix-ähnliches Lehrsystem für PCs. Klein, übersichtlich, als Microkernel gebaut: Treiber und Dateisysteme möglichst außerhalb des Kerns. Für das Studium ideal. Als vollwertiges PC-System für viele Nutzer zu eng lizenziert und zu begrenzt.

Genau in dieser Lücke – freies Userspace vorhanden, brauchbarer freier Kernel für den 386-PC fehlte – beginnt Linux.

Linus Torvalds und die ersten Kernel

1991 war Linus Torvalds Informatikstudent an der Universität Helsinki. Er wollte verstehen, wie ein 386-Prozessor im geschützten Modus arbeitet, und ein System, das über MINIX hinausging. Am 25. August 1991 schrieb er in die MINIX-Newsgroup, er arbeite an einem freien Betriebssystem, „just a hobby, won't be big and professional like gnu“, für 386- und 486-AT-Klone.

Die erste öffentliche Version 0.01 folgte im September 1991, die als nutzbar angekündigte 0.02 am 5. Oktober 1991: ein kleiner Kernel, rund zehntausend Zeilen, noch auf MINIX zum Entwickeln angewiesen. Der Arbeitsname war zeitweise Freax. Auf dem FTP-Server der Hochschule landete das Archiv unter Linux – der Name blieb.

Wichtig für die Einordnung: Torvalds schrieb den Kernel neu. Er kopierte nicht den MINIX-Quelltext. Die Ähnlichkeit lag in der Unix-Idee und zeitweise im Dateisystemlayout, nicht in einer Code-Abstammung von AT&T-Unix.

Anfang 1992 stellte er den Kernel unter die GNU General Public License Version 2. Ab dem 1. Februar 1992 galt: Studium, Änderung und Weitergabe sind erlaubt, solange abgeleiteter Kernel-Code unter derselben Copyleft-Lizenz bleibt. Die GPL schuf die Lizenzgrundlage dafür, dass andere den Kernel verändern und weitergeben konnten.

💡 Einordnung: Die Debatte zwischen Tanenbaum und Torvalds 1992 drehte sich um Microkernel gegen monolithischen Kernel. Tanenbaum hielt den monolithischen Entwurf für überholt. Torvalds hielt ihn für einfacher und schneller auf realer PC-Hardware. Linux blieb monolithisch – mit Modulen, die Treiber nachträglich laden, ohne den ganzen Kernel neu zu bauen.

Linux 1.0 erschien am 14. März 1994. Seither pflegt Torvalds den Hauptzweig; stabile Korrekturen betreut unter anderem Greg Kroah-Hartman. Der Quellbaum liegt auf kernel.org. Dort ist der Stable-Zweig derzeit die 7.2-Reihe (aktuell 7.2.5); parallel laufen Longterm-Zweige, unter anderem 6.18, die Distributionen über Jahre mit Fehler- und Sicherheitskorrekturen versorgen. Deine Installation nutzt fast immer den Kernel der Distro, nicht den tagesaktuellen Mainline-Tar.

GPL und das Entwicklungsmodell

Ein klassischer Unix-Kernel gehörte einer Firma oder einer Universitätslinie. Patches liefen über Lizenzen und Produktzyklen. Der Linux-Kernel ist ein gemeinsames Git-Archiv:

• Subsystem-Maintainer nehmen Patches für Treiber, Dateisysteme, Netz oder Architektur an.
• Torvalds merget in das Hauptarchiv.
• Stable- und Longterm-Zweige konzentrieren sich auf Korrekturen und ausgewählte Backports statt auf neue Feature-Serien.

Für dich folgt daraus etwas Nüchternes: Du musst den Kernel nicht selbst bauen, um ihn zu verstehen. Du musst wissen, welche Version läuft – und dass ein Paketupdate erst nach dem Reboot der laufende Kernel ist.

Linux-Kernel und Unix-Kernel im Vergleich

Linux ist Unix-ähnlich, nicht „Unix“ im Marken- oder Zertifizierungssinn. Im Terminal merkst du das kaum: ls fühlt sich vertraut an. Unter der Haube ist es ein anderes Programm mit anderer Lizenz und anderer ABI.

POSIX beschreibt portable Schnittstellen. Viele Linux-Systeme sind POSIX-nah. Die teure Single UNIX Specification-Zertifizierung holen sich Linux-Distributionen in der Regel nicht. Kommerzielle Unix-Systeme taten das historisch, weil die Marke „UNIX“ ein Verkaufsargument war.

BSD-Kernel (FreeBSD, OpenBSD, NetBSD) stehen Linux näher als altes System-V-Unix: offener Quellcode, monolithisch, Unix-Erbe. Unterschiede bleiben spürbar. BSD liefert Kernel und Userspace als ein System. Linux liefert den Kernel; die Distro entscheidet über Init, C-Bibliothek und Werkzeuge. Linux lädt Treiber alltagsüblich als Module. BSD baut vieles fester in den Kernel, mit eigener Modultradition.

Deshalb fühlt sich ls auf Solaris, FreeBSD und Linux ähnlich an. Der Kernel darunter ist trotzdem jeweils ein anderes Programm.

⚠️ Warnung: „Linux ist ein Unix“ ist als Kurzformel schlampig. Korrekt: Linux ist ein Unix-ähnlicher Kernel. Programme lassen sich oft portieren. Binaries, Kernel-Module und interne Schnittstellen sind nicht dieselben.

Die Aufgaben des Kernels

Stell dir vor, jedes Programm dürfte CPU, Speicher und Platte selbst bedienen. Das endet in Chaos. Der Kernel ist der Vermittler, der das verhindert.

Prozesse und Scheduling

Jedes laufende Programm ist ein Prozess (genauer: ein oder mehrere Threads). Der Kernel erzeugt sie, trennt ihre Adressräume und entscheidet, wer die CPU als Nächstes bekommt. Das ist Scheduling.

Du merkst es, wenn ein Compiler die Maschine lastet und die Shell trotzdem noch reagiert. Der Kernel verteilt Zeitscheiben. Er friert das System nicht für ein Programm ein.

Typischerweise startet eine Shell externe Programme über Mechanismen wie fork und exec – beides Kernel-Arbeit. Interne Built-ins wie cd bleiben in der Shell, weil ein Kindprozess das Verzeichnis der Eltern-Shell nicht ändern kann.

Speicher

Dein Programm verhält sich erst einmal so, als hätte es seinen Speicher für sich allein. Hat es natürlich nicht. Der Kernel hält diese Trennung aufrecht und entscheidet, welche virtuellen Speicherseiten tatsächlich im RAM landen.

Jedes Programm sieht deshalb einen virtuellen Adressraum. Der Kernel ordnet virtuelle Speicherseiten physischem RAM zu. Unter Speicherdruck kann er ungenutzte Seiten verwerfen oder – sofern Swap vorhanden ist – auslagern. Ein Prozess darf den Speicher eines anderen Prozesses nicht einfach lesen. Genau das ist die Grenze zwischen Userspace-Programmen. Der Kernel selbst liegt außerhalb dieses unprivilegierten Raums.

Systemaufrufe

Userspace kommt nicht einfach in den Kernel. Der Weg heißt Systemaufruf. Typische Beispiele, begrifflich, keine C-Referenz:

• open / read / write / close für Dateien und viele Geräte,
• fork / execve / exit für Prozesse,
• socket / connect / bind für Netz,
• mmap für Speicherabbildungen.

1. Userspacecat datei.txt ruft open() / read()
2. Linux-KernelVFS + Treiber; Rechte prüfen, Puffer füllen
3. DatenträgerDateisystem liefert die Bytes
4. Zurück in den ProzessAusgabe auf stdout

cat öffnet keine Platine. cat ruft den Kernel. Der Kernel prüft Rechte, findet den Dateisystemtreiber und liefert Bytes zurück.

Treiber und Hardware

Ohne passenden Treiber kann der Kernel mit deiner Netzwerkkarte herzlich wenig anfangen. Dass sie im PCIe-Slot steckt, reicht eben nicht. Erst der Treiber weiß, wie dieses konkrete Stück Hardware angesprochen werden muss – bis runter zu Registern und DMA.

Dasselbe gilt für Grafik, Speichercontroller, USB und Dateisystemtreiber. Ein fehlender Treiber zeigt sich als „Gerät nicht erkannt“, nicht als magischer Userspace-Fehler.

Dateisysteme

Anwendungen sehen Pfade wie /etc/hosts. Darunter liegen ext4, XFS, btrfs, NFS oder etwas ganz anderes. Der Kernel setzt das Virtual File System (VFS) dazwischen. Dieselbe open-Familie bedient lokale Platten, Netzfreigaben und Spezialdateien unter /proc und /sys.

/proc und /sys sind virtuelle Dateisysteme. Ihre Inhalte liegen nicht wie normale Dateien auf der SSD, sondern bilden laufenden Kernel- und Systemzustand ab. Deshalb kannst du den laufenden Kernel dort befragen, ohne eine Konfigurationsdatei zu erraten.

Netzwerk

Sockets, Routing, Firewall-Haken, die TCP/IP-Verarbeitung: Das sitzt im Kernel. Userspace-Programme sprechen connect und send. Ob Pakete die NIC verlassen, entscheidet der Netzwerkstack plus Treiber. Tools wie ss oder ip lesen diesen Zustand. Sie sind nicht der Stack.

Rechte und Isolation

Jeder Prozess läuft mit einer Identität (UID, GID, ergänzend Capabilities). Dateizugriff prüft der Kernel gegen Inode-Rechte. Details stehen im Artikel zu chmod. Hier reicht der Satz: Die Shell kann Rechte nicht „überstimmen“. Verweigert der Kernel den Zugriff, bleibt Permission denied.

Das ist übrigens einer der großen Unterschiede zwischen Container und VM: Ein Container bringt keinen eigenen Kernel mit. Er benutzt schlicht den vom Host. Eine VM dagegen bootet ihren eigenen. Deshalb ist ein Container eben keine kleine VM, auch wenn es auf den ersten Blick gern so aussieht. Leichtgewicht hat hier einen Preis: Du hängst an der Kernel-Version des Hosts.

Module: nachladbarer Kernel-Code

Ein Desktop-Kernel enthält nicht jeden WLAN-Chip der Welt fest verdrahtet. Viele Treiber kommen als Modul (.ko). Der Kernel lädt sie bei Bedarf, oft automatisch über udev.

🔧 Praktisches Beispiel:

Schau dir die geladenen Module an:

lsmod | head

Details zu einem konkreten Modul, sofern der Name auf deinem System existiert:

modinfo xhci_hcd

lsmod listet, was jetzt im Kernel hängt. modinfo beschreibt eine Moduldatei, auch wenn sie gerade nicht geladen ist.

⚠️ Warnung: rmmod oder modprobe -r entlädt Kernel-Code. Auf einem Rechner, dessen Netz- oder Plattenzugriff genau dieses Modul braucht, ist das ein schneller Weg zu einem hängenden System. Als Übung reicht das Lesen. Entladen gehört nicht in den Anfängeralltag.

Den laufenden Kernel ansehen

Theorie ohne den eigenen Rechner bleibt Folklore. Die folgenden Befehle sind lesend. Root brauchst du dafür in der Regel nicht; dmesg kann auf manchen Systemen eingeschränkt sein.

Version und Build

🔧 Praktisches Beispiel:

uname -r
uname -a

-r ist die laufende Freigabe, zum Beispiel ein Distro-String wie 6.8.0-60-generic oder eine 7.2-Variante auf einer Rolling-Distribution. -a ergänzt Maschine, Prozessorangabe und den Build-Text.

Dieselbe Information liegt im Kernel selbst:

cat /proc/version

/proc/version ist kein Archiv auf der Platte, sondern eine Auskunft des laufenden Kernels.

💡 Tipp: Vergleiche uname -r mit dem, was der Paketmanager als installiert anzeigt. Weichen beide ab, ist ein neuer Kernel installiert, aber noch nicht gebootet.

Meldungen beim Start

Der Kernel schreibt in einen Ringpuffer. Nach dem Boot steht dort, welche Hardware er gefunden hat und welche Treiber er gebunden hat.

journalctl -k -b | less

-k beschränkt auf Kernelmeldungen, -b auf den aktuellen Boot. Unter systemd ist das meist der bequemste Weg. Den Ringpuffer selbst liest du so:

dmesg | less

Auf vielen Distributionen dürfen unprivilegierte Benutzer dmesg nicht lesen. Der Kernel-Parameter kernel.dmesg_restrict steuert das. Liefert dmesg nichts oder Operation not permitted, bleibt journalctl -k oder ein Aufruf mit entsprechenden Rechten.

Geladene Module und Hardwareblick

lsmod
ls /sys/module | wc -l

/sys/module ist die Sysfs-Sicht auf Module. Wieder Kernel-Zustand, keine Konfigurationsdatei, die du von Hand pflegst.

Paket und laufende Version

Auf Debian und Ubuntu zeigt das Kernel-Image-Paket, was installiert ist:

uname -r
dpkg -l 'linux-image-*' | awk '/^ii/ { print $2, $3 }'

Auf Fedora oder RHEL analog rpm -q kernel bzw. dnf list installed kernel. Der Paketname ist Distro-Sache. Die Regel ist überall gleich: installiert ≠ laufend, solange du nicht neu gestartet hast.

❗ Typische Fehlerquelle: Nach einem Kernel-Update wirkt „nichts anders“, bis der Rechner den neuen Kernel geladen hat. Dienste im Userspace können ohne Reboot neu starten. Der Kernel nicht.

Vom Einschalten bis zum Userspace

Beim Einschalten läuft noch kein Linux. Die Firmware (UEFI oder älteres BIOS) startet den Bootloader. Der Bootloader lädt den Kernel und meist ein initramfs: ein kleines, temporäres Wurzeldateisystem im RAM, damit der Kernel Platten- und Crypto-Treiber hat, bevor das eigentliche Root-Dateisystem da ist.

1. FirmwareUEFI / BIOS
2. Bootloaderz. B. GRUB
3. Linux-Kernel + initramfs
4. Erstprozesssystemd / init
5. UserspaceDienste, Login, Shell, Desktop

Ab da ist der Kernel „nur noch“ Vermittler – allerdings der Vermittler, ohne den kein Dienst existiert. GRUB-Menüeinträge, UKI, Secure Boot: eigene Baustellen.

Was du als Anfänger bewusst lässt

Den Kernel zu verstehen heißt nicht, ihn zu bauen.

Einen eigenen Kernel zu bauen bringt dir als Anfänger erst einmal erstaunlich wenig. Solange deine Distribution einen passenden Kernel liefert, lass sie ihren Job machen.

• Alte Kernel-Pakete erst löschen, wenn du mit dem neuen erfolgreich gebootet hast. Der Bootloader-Eintrag des Vorgängers ist die Rettung, wenn ein Update nicht passt.
• Kein rmmod auf Speicher-, Platten- oder Netztreibern „zum Ausprobieren“.
• Mainline von kernel.org ist für Entwickler und Distro-Packager. Auf dem Arbeitsrechner bleibt der Distro-Kernel.

Wer später Kernel baut, braucht eine Testmaschine, nicht das einzige Laptop.

Befehlsreferenz (Cheatsheet)

Weiterführende Ressourcen

Fazit

Wer Linux administriert, arbeitet ständig mit dem Kernel, auch ohne ihn selbst zu kompilieren. uname, /proc, /sys, Kernel-Logs und Module sind deshalb keine Spezialthemen für Kernel-Entwickler, sondern normale Werkzeuge zur Systemanalyse.

Nach einem Update entscheidet nicht das Paket, sondern der nächste Boot, welcher Kernel wirklich läuft. Genau diese Unterscheidung trennt eine funktionierende Diagnose von Rätselraten.

💡 Tipp: Notiere dir nach dem nächsten Distro-Update uname -r vor und nach dem Reboot. Der Unterschied ist der Kernel, nicht das Gefühl, „es sei irgendwie aktualisiert“.