Kernel einfach erklärt: Aufgaben, Funk­ti­ons­wei­se und Arten

Wer mit einem Be­triebs­sys­tem arbeitet, arbeitet auch mit einem Kernel – meist ohne es zu bemerken. Der Kernel ist der zentrale Be­stand­teil eines Be­triebs­sys­tems und bildet die Schnitt­stel­le zwischen Hardware und Software. Er läuft vom Start bis zum Her­un­ter­fah­ren des Rechners un­un­ter­bro­chen im Hin­ter­grund.

Als Programm mit den höchsten Rechten steuert der Kernel alle Zugriffe auf Prozessor und Ar­beits­spei­cher, bindet über Treiber die Geräte ein und verteilt die Res­sour­cen des Systems möglichst effizient auf die laufenden Programme.

Was ist ein Kernel?

Ein Kernel (deutsch: Be­triebs­sys­tem­kern oder Sys­tem­kern) ist der Teil eines Be­triebs­sys­tems, der mit un­ein­ge­schränk­ten Rechten direkt auf die Hardware zugreift. Er verwaltet Prozessor, Ar­beits­spei­cher und Geräte und stellt diese Res­sour­cen den An­wen­dun­gen kon­trol­liert über Sys­tem­auf­ru­fe zur Verfügung. An­wen­dun­gen greifen also nie selbst auf die Hardware zu, sondern bitten den Kernel darum.

Das gilt un­ab­hän­gig davon, ob es sich um ein Linux-, macOS- oder Windows-System handelt, ob der Kernel auf einem Smart­phone, einem Server oder in einer vir­tu­el­len Maschine läuft – etwa bei einer Vir­tua­li­sie­rung mit KVM. Der Begriff stammt aus dem Eng­li­schen: „Kernel“ bedeutet so viel wie „Kern“ oder „Samenkorn“ – passend für den innersten Teil des Systems.

Wie ist ein Kernel aufgebaut?

Wie ein Kernel intern or­ga­ni­siert ist, hängt von seiner Ar­chi­tek­tur ab (mehr dazu im Abschnitt zu den Kernel-Arten). Zur Ver­an­schau­li­chung lässt er sich aber als Folge von Schichten (Layern) be­schrei­ben, die von der Hardware bis zu den An­wen­dun­gen reichen:

• Die unterste Schicht ist die Schnitt­stel­le zur Hardware (Pro­zes­so­ren, Speicher und Geräte). Sie enthält ma­schi­nen­na­hen, oft ar­chi­tek­tur­spe­zi­fi­schen Code, etwa für die Be­hand­lung von In­ter­rupts oder die An­steue­rung von Netzwerk- und PCI-Express-Con­trol­lern.
• Darauf liegt die Spei­cher­ver­wal­tung, die den Ar­beits­spei­cher verteilt und jedem Prozess einen eigenen vir­tu­el­len Adress­raum be­reit­stellt.
• Die Pro­zess­ver­wal­tung mit dem Scheduler ent­schei­det, welcher Prozess wann und wie lange Re­chen­zeit erhält, und er­mög­licht so Mul­ti­tas­king.
• Die Ge­rä­te­ver­wal­tung (Device Ma­nage­ment) bindet Hardware über Ge­rä­te­trei­ber ein.
• Das Da­tei­sys­tem or­ga­ni­siert, wie Dateien und Ver­zeich­nis­se auf Da­ten­trä­gern wie SSDs oder Fest­plat­ten abgelegt und wie­der­ge­fun­den werden.
• Ganz oben steht die Sys­tem­auf­ruf­schnitt­stel­le (englisch: System Call Interface, SCI), über die An­wen­dun­gen die Dienste des Kernels anfordern.

Wo endet der Kernel?

Der Kernel deckt den Weg von der Hardware bis zur Sys­tem­auf­ruf­schnitt­stel­le ab. Alles darüber läuft außerhalb des Kernels: Sys­tem­diens­te, Bi­blio­the­ken, An­wen­dun­gen und auch die Shell. Die Shell ist ein ge­wöhn­li­ches Programm, über das Nut­ze­rin­nen und Nutzer mit dem System in­ter­agie­ren – entweder text­ba­siert in der Kom­man­do­zei­le (z. B. Bash oder Power­Shell) oder über eine grafische Ober­flä­che (Graphical User Interface, GUI). An­schau­lich ist das Bild eines Kerns, um den die Shell wie ein Ring liegt.

Wie kom­mu­ni­zie­ren Programme mit dem Kernel?

Ein Programm, das zum Beispiel eine Datei schreiben, Speicher anfordern oder eine Netz­werk­ver­bin­dung öffnen will, sendet einen Sys­tem­auf­ruf (englisch: System Call) an den Kernel. Dazu nutzt es einen spe­zi­el­len Pro­zes­sor­be­fehl, der die CPU vom ein­ge­schränk­ten Be­nut­zer­mo­dus in den pri­vi­le­gier­ten Ker­nel­mo­dus um­schal­tet. Der Kernel prüft die Anfrage, etwa ob der Prozess die nötigen Rechte besitzt, führt sie aus und gibt das Ergebnis an das Programm zurück.

Der Kernel muss die Anfrage dabei nicht erst „in Ma­schi­nen­spra­che über­set­zen“: Er liegt selbst als Ma­schi­nen­code vor. Ent­schei­dend ist, dass er im Ker­nel­mo­dus auch pri­vi­le­gier­te Pro­zes­sor­be­feh­le ausführen darf, die normalen Pro­gram­men verwehrt sind – etwa zur Kon­fi­gu­ra­ti­on des Spei­cher­schut­zes oder zur Steuerung von In­ter­rupts. Sys­tem­auf­ru­fe laufen ständig ab, ohne dass An­wen­de­rin­nen und Anwender etwas davon bemerken.

Was sind die Aufgaben eines Kernels?

Die zentrale An­for­de­rung an einen modernen Kernel ist Mul­ti­tas­king: Viele Programme sollen scheinbar gleich­zei­tig laufen, ohne sich ge­gen­sei­tig zu stören. Dabei muss der Kernel zeit­kri­ti­sche Abläufe zu­ver­läs­sig bedienen und zugleich offen für neue Hardware und Er­wei­te­run­gen bleiben. Daraus ergeben sich vier Kern­auf­ga­ben:

1. Spei­cher­ver­wal­tung: Teilt Ar­beits­spei­cher zu, gibt ihn wieder frei und schützt die Spei­cher­be­rei­che der Prozesse vor­ein­an­der.
2. Pro­zess­ver­wal­tung: Erzeugt und beendet Prozesse und bestimmt über den Scheduler, welche Prozesse die CPU wann und wie lange nutzen.
3. Ge­rä­te­ver­wal­tung: Ver­mit­telt über Ge­rä­te­trei­ber zwischen Hardware und Prozessen.
4. Sys­tem­auf­ru­fe und Si­cher­heit: Nimmt Anfragen der Prozesse entgegen und prüft dabei Zu­griffs­rech­te auf Dateien, Speicher und Geräte.

Alles Weitere – Sys­tem­diens­te, Bi­blio­the­ken und An­wen­dungs­soft­ware – läuft außerhalb des Kernels und nutzt ihn nur als Ver­mitt­ler. Das gilt auch für die grafische Ober­flä­che: Unter Linux laufen Display-Server und Desktop-Umgebung voll­stän­dig als normale Programme, sie greifen aber über Kernel-Schnitt­stel­len wie das Direct Rendering Manager (DRM) auf die Gra­fik­hard­ware zu.

Was macht der Kernel beim Sys­tem­start?

Beim Hoch­fah­ren lädt zunächst die Firmware (heute meist UEFI) den Boot­loa­der, zum Beispiel GRUB unter Linux oder den Windows Boot Manager. Der Boot­loa­der lädt dann den Kernel in den Ar­beits­spei­cher und übergibt ihm die Kontrolle. Geschützt ist der Kernel an­schlie­ßend nicht durch den Boot­loa­der, sondern durch den Ker­nel­mo­dus und den Spei­cher­schutz der CPU: Normale Programme können den Spei­cher­be­reich des Kernels weder lesen noch verändern.

Danach in­itia­li­siert der Kernel die Hardware und lädt die nötigen Treiber. An­schlie­ßend startet er den ersten Prozess im Be­nut­zer­mo­dus (unter Linux meist systemd), der wiederum Sys­tem­diens­te und schließ­lich die Anmeldung und die An­wen­der­pro­gram­me startet.

Wie funk­tio­niert ein Kernel?

Zunächst eine Ab­gren­zung: Mit „Kernel“ ist nicht ein Pro­zes­sor­kern gemeint, sondern der Be­triebs­sys­tem­kern. Ein Kernel ist auch keine API und kein Framework – er stellt An­wen­dun­gen aber über die Sys­tem­auf­ru­fe eine eigene Pro­gram­mier­schnitt­stel­le zur Verfügung.

Ker­nel­space und Userspace

Die Arbeit des Kernels bleibt für An­wen­de­rin­nen und Anwender un­sicht­bar. Er läuft in einem eigenen, ge­schütz­ten Spei­cher­be­reich, dem Ker­nel­space. Dateien, Programme, Spiele, Browser – kurzum alles, was Sie am Bild­schirm sehen – laufen im Userspace. Die Ver­bin­dung zwischen beiden Welten bildet die Sys­tem­auf­ruf­schnitt­stel­le.

Ent­spre­chend kennt die CPU zwei Aus­füh­rungs­mo­di:

• Code im Ker­nel­mo­dus hat un­ein­ge­schränk­ten Zugriff auf Hardware und Speicher.
• Code im Be­nut­zer­mo­dus (Usermode) darf nicht direkt auf die Hardware zugreifen und muss dafür Sys­tem­auf­ru­fe nutzen.

Diese Trennung macht das System robust: Stürzt ein Programm im Be­nut­zer­mo­dus ab, beendet der Kernel nur diesen einen Prozess, alle anderen laufen weiter. Ein schwerer Fehler im Ker­nel­mo­dus – etwa in einem feh­ler­haf­ten Treiber – kann dagegen das gesamte System zum Absturz bringen. Unter Linux spricht man dann von einer Kernel Panic, unter Windows vom Blue­screen.

Mul­ti­tas­king und Mehr­kern­pro­zes­so­ren

Ein Pro­zes­sor­kern kann zu jedem Zeitpunkt nur einen Prozess ausführen. Dass trotzdem Dutzende Programme gleich­zei­tig zu laufen scheinen, liegt am Scheduler: Er wechselt in sehr kurzen Abständen zwischen den Prozessen. Bei Mehr­kern­pro­zes­so­ren verteilt der Kernel die Prozesse zu­sätz­lich auf die einzelnen Kerne, sodass dort tat­säch­lich mehrere Prozesse parallel laufen.

Gängige Kernel wie Linux, Windows und XNU verwalten alle Kerne mit einem ge­mein­sa­men Kernel. Einen anderen Ansatz verfolgen Mul­ti­ker­nel-Be­triebs­sys­te­me: Sie behandeln die Kerne eines Pro­zes­sors wie ein Netzwerk un­ab­hän­gi­ger CPUs, auf denen jeweils ein eigener Kernel läuft und die über Nach­rich­ten kom­mu­ni­zie­ren. Dieses Konzept wurde vor allem in der Forschung erprobt, etwa mit dem Be­triebs­sys­tem Barr­el­fi­sh der ETH Zürich und Microsoft Research.

Der Kernel im Be­triebs­sys­tem

Um die Rolle des Kernels ein­zu­ord­nen, hilft es, einen Computer in drei Ebenen zu un­ter­tei­len:

1. Hardware: Die Basis des Systems aus Prozessor, Ar­beits­spei­cher sowie Ein- und Aus­ga­be­ge­rä­ten. Die CPU führt Be­rech­nun­gen sowie Lese- und Schreib­vor­gän­ge im Speicher aus.
2. Kernel: Der Kern des Be­triebs­sys­tems. Er sagt der CPU, was sie tun soll, und verteilt die Hardware-Res­sour­cen.
3. Be­nut­zer­pro­zes­se: Alle laufenden Programme, die der Kernel verwaltet. Er er­mög­licht ihnen auch, un­ter­ein­an­der Daten aus­zu­tau­schen – die so­ge­nann­te In­ter­pro­zess­kom­mu­ni­ka­ti­on (Inter-Process Com­mu­ni­ca­ti­on, IPC).

Welche Kernel-Arten gibt es?

Kernel lassen sich nach ihren Fä­hig­kei­ten un­ter­schei­den: Laufen mehrere Prozesse scheinbar gleich­zei­tig, spricht man von einem Mul­ti­tas­king-Kernel. Kommt eine Benutzer- und Rech­te­ver­wal­tung hinzu, wird daraus ein Mehr­be­nut­zer­sys­tem, auf dem mehrere Benutzer gleich­zei­tig arbeiten können. Die Anmeldung selbst über­neh­men dabei Programme im Userspace; der Kernel ordnet jedem Prozess eine Be­nut­zer­ken­nung zu und setzt die damit ver­bun­de­nen Rechte durch.

Wichtiger für die Ein­ord­nung ist aber die Ar­chi­tek­tur, also die Frage, welche Aufgaben im Kernel selbst und welche außerhalb erledigt werden.

Die drei Kernel-Arten

Nach ihrer Ar­chi­tek­tur lassen sich Kernel in drei Gruppen einteilen:

1. Mo­no­li­thi­scher Kernel: Alle zentralen Funk­tio­nen – Speicher- und Pro­zess­ver­wal­tung, In­ter­pro­zess­kom­mu­ni­ka­ti­on, Da­tei­sys­te­me und Ge­rä­te­trei­ber – laufen gemeinsam im Ker­nel­mo­dus. Das ist schnell, weil keine Umwege nötig sind; ein Fehler in einem Treiber kann aber den ganzen Kernel treffen. Das be­kann­tes­te Beispiel ist Linux. Er ist modular aufgebaut: Treiber und andere Funk­tio­nen lassen sich als Ker­nel­mo­du­le zur Laufzeit nachladen, laufen dann aber ebenfalls im Ker­nel­mo­dus.
2. Mi­kro­ker­nel: Der Kernel ist bewusst minimal gehalten und übernimmt nur die grund­le­gends­ten Aufgaben wie Spei­cher­ver­wal­tung, Sche­du­ling und In­ter­pro­zess­kom­mu­ni­ka­ti­on. Treiber, Da­tei­sys­te­me und Netzwerk-Stacks laufen als ei­gen­stän­di­ge Dienste im Userspace. Stürzt ein solcher Dienst ab, bleibt der Kernel intakt. Der Preis dafür ist zu­sätz­li­cher Kom­mu­ni­ka­ti­ons­auf­wand. Mi­kro­ker­nel kommen vor allem dort zum Einsatz, wo Zu­ver­läs­sig­keit und Si­cher­heit im Vor­der­grund stehen, etwa QNX in Fahr­zeu­gen und In­dus­trie­an­la­gen oder seL4, dessen Kor­rekt­heit formal ma­the­ma­tisch bewiesen wurde. Auch Zircon, der Kernel von Googles Be­triebs­sys­tem Fuchsia, ist ein Mi­kro­ker­nel.
3. Hybrid-Kernel: Er kom­bi­niert beide Ansätze. Er ist nach dem Vorbild eines Mi­kro­ker­nels in Kom­po­nen­ten ge­glie­dert, führt aus Leis­tungs­grün­den aber viele Dienste – darunter Treiber und Da­tei­sys­te­me – im Ker­nel­mo­dus aus. Beispiele sind der Windows-NT-Kernel und XNU, der Kernel von macOS und iOS. XNU verbindet den Mi­kro­ker­nel Mach mit Kom­po­nen­ten aus FreeBSD und dem Treiber-Framework I/O Kit.

Daneben gibt es Spe­zi­al­for­men wie Exokernel und Unikernel, die vor allem in der Forschung bzw. für einzelne Cloud-An­wen­dun­gen genutzt werden.

Welche Kernel sind Open Source?

Der Linux-Kernel ist Open Source und steht unter der GNU General Public License Version 2. Seinen Quellcode sowie ein Archiv aller bis­he­ri­gen Versionen ver­öf­fent­licht das Projekt auf kernel.org. Etwa alle zwei bis drei Monate erscheint eine neue Haupt­ver­si­on; im Oktober 2026 ist das Linux 7.3. Für Server und Geräte mit langen Lauf­zei­ten gibt es zu­sätz­lich Longterm-Versionen (LTS), die über mehrere Jahre Si­cher­heits- und Feh­ler­kor­rek­tu­ren erhalten. Neben C wird seit Linux 6.1 auch die Pro­gram­mier­spra­che Rust im Kernel verwendet, vor allem für neue Treiber; seit Ende 2025 gilt Rust dort nicht mehr als Ex­pe­ri­ment.

Auch Apple ver­öf­fent­licht den Quellcode des XNU-Kernels als Teil des Open-Source-Be­triebs­sys­tems Darwin. Der Windows-NT-Kernel ist dagegen pro­prie­tär. Microsoft setzt aber selbst einen Linux-Kernel ein: Das Windows Subsystem for Linux in der Version WSL 2 betreibt einen echten, von Microsoft an­ge­pass­ten Linux-Kernel in einer schlanken vir­tu­el­len Maschine. Dessen Quellcode ist ebenfalls öf­fent­lich.

Welche Rolle spielt der Kernel auf Servern?

Auf Servern wirkt sich der Kernel un­mit­tel­bar auf Sta­bi­li­tät, Si­cher­heit und Leistung aus. Für die Praxis sind vor allem drei Punkte wichtig:

• Virtuelle Maschinen und Container: Bei einem vir­tu­el­len Server auf Basis von KVM läuft in jeder vir­tu­el­len Maschine ein eigener Kernel. Sie können dort also Be­triebs­sys­tem und Kernel-Version selbst wählen. Container wie Docker dagegen teilen sich den Kernel des Host-Systems und trennen Prozesse über Kernel-Funk­tio­nen wie Name­spaces und cgroups. Das spart Res­sour­cen, bedeutet aber auch, dass alle Container von der Kernel-Version und von Si­cher­heits­lü­cken des Hosts abhängen.
• Kernel-Version prüfen: Unter Linux zeigt der Befehl uname -r an, welche Kernel-Version gerade läuft.
• Kernel-Updates: Si­cher­heits­up­dates für den Kernel werden in der Regel erst nach einem Neustart wirksam. Für Systeme, die möglichst ohne Un­ter­bre­chung laufen sollen, gibt es unter Linux das so­ge­nann­te Liv­e­patching, mit dem sich kritische Kor­rek­tu­ren in den laufenden Kernel ein­spie­len lassen.