Betriebssystem
Jedes Programm auf einem Computer braucht Zugriff auf den Prozessor, den Arbeitsspeicher und Geräte wie Festplatten oder Netzwerkkarten. Eine zentrale Softwareschicht übernimmt die Verwaltung dieser Ressourcen, teilt sie zwischen laufenden Programmen auf und sorgt dafür, dass sich Programme nicht gegenseitig stören. Diese Schicht heißt Betriebssystem.
Was ein Betriebssystem tatsächlich tut
Ein Betriebssystem (englisch: Operating System, kurz OS) ist die Software, die direkt auf der Hardware läuft und allen anderen Programmen eine einheitliche Umgebung bereitstellt. Es übernimmt drei Kernaufgaben: Ressourcenverwaltung, Prozesssteuerung und Abstraktion.
Ressourcenverwaltung bedeutet, dass das Betriebssystem den verfügbaren Arbeitsspeicher, die Rechenzeit des Prozessors und den Zugang zu Ein-/Ausgabegeräten auf die laufenden Programme verteilt. Kein Programm greift direkt auf die Hardware zu. Stattdessen stellt das Betriebssystem definierte Schnittstellen bereit, sogenannte Systemaufrufe (System Calls).
Beispiel: Ein Textverarbeitungsprogramm fordert über einen Systemaufruf Speicher an. Das Betriebssystem prüft, ob genügend freier Speicher vorhanden ist, reserviert einen Bereich und gibt dem Programm eine Adresse zurück. Das Programm kennt weder die physische Speicheradresse noch die konkrete Hardware.
Beispiel: Ein Webserver und eine Datenbank laufen gleichzeitig auf demselben Rechner. Das Betriebssystem sorgt dafür, dass beide Programme abwechselnd Rechenzeit erhalten und keines das andere blockiert.
Fachliche Einordnung: Die Trennung zwischen Benutzerprogramm und Betriebssystemkern (Kernel) gehört zu den grundlegenden Architekturprinzipien seit den 1960er-Jahren. Sie ermöglicht, dass fehlerhafte Programme nicht das gesamte System zum Absturz bringen.
Der Kern des Systems
Im Zentrum jedes Betriebssystems steht der Kernel. Er läuft im privilegierten Modus des Prozessors (Kernel Mode) und hat uneingeschränkten Zugriff auf die Hardware. Alle anderen Programme laufen im eingeschränkten Modus (User Mode) und dürfen nur über Systemaufrufe auf Kernel-Funktionen zugreifen.
Es gibt zwei grundlegende Kernel-Architekturen:
Beim monolithischen Kernel befinden sich alle Betriebssystemfunktionen in einem einzigen, großen Programmblock. Dateisystem, Netzwerkprotokoll, Gerätetreiber: alles läuft im Kernel Mode. Der Vorteil ist Geschwindigkeit, weil Funktionsaufrufe innerhalb des Kernels keine Kontextwechsel erfordern. Der Nachteil ist, dass ein Fehler in einem Treiber den gesamten Kernel zum Absturz bringen kann.
Beim Microkernel enthält der Kern nur das Minimum: Prozessverwaltung, Speicherverwaltung und Interprozesskommunikation. Alle weiteren Dienste (Dateisystem, Treiber, Netzwerk) laufen als eigenständige Prozesse im User Mode. Ein Treiberfehler bringt dann nur den betroffenen Dienst zum Absturz, nicht das gesamte System.
Beispiel: Linux verwendet einen monolithischen Kernel. Wenn ein fehlerhafter Grafiktreiber geladen wird, kann das gesamte System einfrieren. In einem Microkernel-System wie QNX würde der fehlerhafte Treiber isoliert neu gestartet, während das restliche System weiterläuft.
In der Praxis verwenden die meisten modernen Betriebssysteme einen Hybrid-Ansatz. Windows NT beispielsweise hat einen Microkernel-inspirierten Aufbau, lagert aber aus Leistungsgründen bestimmte Dienste zurück in den Kernel Mode.
Beispiel: macOS basiert auf XNU, einem Hybrid-Kernel. Er kombiniert den Mach-Microkernel mit Teilen des monolithischen BSD-Kernels und erzielt damit einen Kompromiss zwischen Stabilität und Durchsatz.
Wie Programme gleichzeitig laufen
Ein einzelner Prozessorkern kann zu jedem Zeitpunkt nur eine Anweisung ausführen. Trotzdem scheinen auf einem modernen Rechner Dutzende Programme gleichzeitig zu laufen. Das Betriebssystem erzeugt diesen Eindruck durch schnelles Umschalten zwischen den Programmen. Dieses Verfahren heißt präemptives Multitasking.
Jedes laufende Programm ist aus Sicht des Betriebssystems ein Prozess. Jeder Prozess besitzt einen eigenen Adressraum (also einen isolierten Speicherbereich), einen Programmzähler und einen Satz von Registerwerten. Der Scheduler entscheidet, welcher Prozess als Nächstes Rechenzeit bekommt.
Beispiel: Auf einem Server laufen 200 Prozesse, aber nur 8 Prozessorkerne sind verfügbar. Der Scheduler teilt jedem Prozess Zeitscheiben zu (typisch: 1 bis 10 Millisekunden) und wechselt dann zum nächsten. Bei 200 Prozessen und 10-ms-Zeitscheiben durchläuft der Scheduler alle Prozesse in etwa 250 Millisekunden. Für den Benutzer sieht das wie Gleichzeitigkeit aus.
Innerhalb eines Prozesses gibt es häufig mehrere Threads. Threads teilen sich den Adressraum ihres Elternprozesses, haben aber jeweils eigene Register und einen eigenen Stack. Das macht den Wechsel zwischen Threads schneller als den Wechsel zwischen Prozessen, weil kein Adressraumwechsel nötig ist.
Beispiel: Ein Webbrowser verwendet einen Thread für die Darstellung der Seite, einen für JavaScript-Ausführung und einen für das Laden von Bildern. Alle drei Threads greifen auf denselben Speicherbereich des Browser-Prozesses zu, arbeiten aber unabhängig voneinander.
Speicherverwaltung und virtueller Adressraum
Jeder Prozess sieht einen eigenen, zusammenhängenden Adressraum, obwohl der physische Arbeitsspeicher fragmentiert und von vielen Prozessen geteilt wird. Diese Illusion erzeugt die Memory Management Unit (MMU) der CPU in Zusammenarbeit mit dem Betriebssystem. Das Verfahren heißt virtuelle Speicherverwaltung (Virtual Memory).
Der Adressraum eines Prozesses wird in Seiten (Pages) unterteilt, typischerweise 4 Kilobyte groß. Das Betriebssystem führt für jeden Prozess eine Seitentabelle (Page Table), die virtuelle Adressen auf physische Adressen abbildet. Wenn ein Prozess auf eine Adresse zugreift, die aktuell nicht im physischen Speicher liegt, löst die MMU einen Page Fault aus. Das Betriebssystem lädt dann die benötigte Seite von der Festplatte in den Arbeitsspeicher.
Beispiel: Ein System hat 8 GB Arbeitsspeicher, aber die laufenden Programme beanspruchen insgesamt 12 GB. Das Betriebssystem lagert selten genutzte Seiten auf die Festplatte aus (Swap). Greift ein Programm auf eine ausgelagerte Seite zu, entsteht ein Page Fault, und das Betriebssystem lädt die Seite zurück. Der Zugriff auf die Festplatte dauert dabei etwa 10.000 Mal länger als ein Speicherzugriff im RAM.
Beispiel: Zwei Prozesse verwenden dieselbe Programmbibliothek (z.B. libc). Das Betriebssystem lädt den Code der Bibliothek nur einmal in den physischen Speicher und bildet ihn in beiden Adressräumen ab. Beide Prozesse sehen die Bibliothek an ihrer eigenen virtuellen Adresse, teilen sich aber dieselben physischen Speicherseiten. Dieses Verfahren heißt Shared Memory Mapping.
Dateisysteme und persistente Speicherung
Der Arbeitsspeicher ist flüchtig: bei einem Neustart gehen alle Daten verloren. Für dauerhafte Speicherung stellt das Betriebssystem ein Dateisystem bereit. Es organisiert Daten in einer hierarchischen Struktur aus Verzeichnissen und Dateien und abstrahiert die physische Speicherung auf der Festplatte oder SSD.
Unterschiedliche Dateisysteme optimieren für unterschiedliche Anforderungen. ext4 (Linux-Standard) bietet Journaling, das bei Stromausfällen die Konsistenz der Metadaten sicherstellt. ZFS bietet zusätzlich Prüfsummen auf Datenebene und erkennt stille Datenfehler (Bit Rot). NTFS (Windows) unterstützt feingranulare Zugriffsrechte pro Datei und Verzeichnis.
Beispiel: Eine Datenbank schreibt einen neuen Datensatz. Das Dateisystem schreibt zunächst die geplante Änderung in ein Journal (Log), bevor es die eigentlichen Daten auf die Platte schreibt. Wenn das System während des Schreibvorgangs abstürzt, kann es beim nächsten Start anhand des Journals den konsistenten Zustand wiederherstellen.
Das Betriebssystem stellt für Dateizugriffe eine einheitliche Schnittstelle bereit: öffnen, lesen, schreiben, schließen. Ob die Datei auf einer lokalen SSD, einer Netzwerkfreigabe oder in einem verschlüsselten Container liegt, ist für das Programm transparent.
Beispiel: Ein Backup-Programm liest Dateien über dieselbe Schnittstelle, unabhängig davon, ob das darunterliegende Dateisystem ext4, Btrfs oder ein FUSE-basiertes Netzwerkdateisystem ist. Das Betriebssystem leitet die Aufrufe an den passenden Treiber weiter.
Schutzmechanismen und Zugriffssteuerung
Ein Betriebssystem muss verhindern, dass Programme auf Ressourcen zugreifen, für die sie keine Berechtigung haben. Die Schutzmechanismen greifen auf mehreren Ebenen.
Auf Prozessebene isoliert die virtuelle Speicherverwaltung jeden Prozess. Ein Prozess kann den Speicher eines anderen Prozesses nicht lesen oder verändern, weil seine Seitentabelle nur eigene Speicherbereiche enthält.
Auf Dateisystemebene kontrollieren Zugriffsrechte (Permissions), welche Benutzer und Gruppen eine Datei lesen, schreiben oder ausführen dürfen. Unix-Systeme verwenden ein Modell mit Besitzer, Gruppe und Anderen (Owner, Group, Others). Feinere Steuerung bieten Access Control Lists (ACLs).
Auf Systemebene trennt der Privilege Ring zwischen Kernel Mode und User Mode. Programme im User Mode können keine privilegierten Befehle ausführen (z.B. direkten Zugriff auf I/O-Ports). Jeder Versuch löst eine Ausnahme (Exception) aus, die der Kernel abfängt.
Beispiel: Ein Schadprogramm versucht, den Speicher des Passwortmanagers zu lesen. Das Betriebssystem blockiert den Zugriff, weil die Seitentabelle des Schadprogramms keine Einträge für den Speicherbereich des Passwortmanagers enthält. Der Versuch führt zu einem Segmentation Fault und das Schadprogramm wird beendet.
Beispiel: Auf einem Linux-Server hat die Konfigurationsdatei /etc/shadow die Rechte 640. Nur root (Besitzer) darf lesen und schreiben, die Gruppe shadow darf lesen, alle anderen Benutzer haben keinen Zugriff. Ein normaler Benutzerprozess erhält beim Versuch, die Datei zu öffnen, die Fehlermeldung "Permission denied".
Darüber hinaus setzen moderne Betriebssysteme Mandatory Access Control (MAC) ein. Systeme wie SELinux oder AppArmor definieren Regeln, die auch Prozesse mit Root-Rechten einschränken. Damit begrenzt ein kompromittierter Dienst den Schaden auf seinen definierten Wirkungsbereich.
Varianten und Einsatzbereiche
Betriebssysteme sind nicht auf Desktop-Rechner und Server beschränkt. Je nach Einsatzgebiet stellen sie unterschiedliche Eigenschaften in den Vordergrund.
Server-Betriebssysteme optimieren für Durchsatz und Stabilität. Sie laufen oft monatelang ohne Neustart und verwalten Tausende gleichzeitiger Netzwerkverbindungen. Linux-Distributionen wie Debian oder RHEL dominieren dieses Segment.
Echtzeit-Betriebssysteme (Real-Time Operating Systems, RTOS) garantieren, dass bestimmte Aufgaben innerhalb einer festgelegten Zeitspanne abgeschlossen werden. Sie kommen in der Fahrzeugelektronik, der Medizintechnik und der industriellen Steuerung zum Einsatz.
Beispiel: Das Antiblockiersystem eines Fahrzeugs läuft auf einem RTOS. Wenn ein Sensor Blockiergefahr meldet, muss die Bremskraftregelung innerhalb weniger Millisekunden reagieren. Ein Desktop-Betriebssystem mit seinem präemptiven Scheduler könnte diese Zeitgarantie nicht zuverlässig einhalten.
Eingebettete Betriebssysteme laufen auf Geräten mit stark begrenzten Ressourcen: Waschmaschinen, Router, Smartwatches. Sie belegen oft nur wenige Kilobyte Speicher und bieten nur die minimal nötigen Funktionen.
Beispiel: Ein WLAN-Router verwendet ein eingebettetes Linux (OpenWrt) mit etwa 16 MB Flash-Speicher. Das Betriebssystem enthält nur Netzwerkstack, Firewall und eine minimale Shell. Dateiverwaltung oder grafische Oberflächen fehlen vollständig.
Containerisierung verändert die Rolle des Betriebssystems auf Servern. Container teilen sich den Kernel des Host-Betriebssystems, laufen aber in isolierten Namensräumen (Namespaces) mit eigenen Dateisystemen und Netzwerk-Konfigurationen. Das Betriebssystem stellt hier die Isolationsmechanismen bereit, während der Container nur die Anwendung und ihre Abhängigkeiten enthält.
Grenzen und Einordnung
Ein Betriebssystem abstrahiert Hardware, aber diese Abstraktion hat Kosten. Jeder Systemaufruf erfordert einen Kontextwechsel zwischen User Mode und Kernel Mode. Bei hochfrequenten I/O-Operationen kann dieser Overhead erheblich werden.
Beispiel: Hochleistungs-Netzwerkanwendungen umgehen den Betriebssystem-Netzwerkstack mit Technologien wie DPDK (Data Plane Development Kit). Dabei greift die Anwendung direkt auf die Netzwerkkarte zu, ohne den Kernel einzubeziehen. Der Durchsatz steigt, aber die Isolation durch das Betriebssystem entfällt.
Virtuelle Speicherverwaltung schützt Prozesse voreinander, schützt aber nicht gegen Seitenkanalangriffe. Schwachstellen wie Spectre und Meltdown (2018) zeigten, dass Prozesse über das Zeitverhalten von Speicherzugriffen Informationen aus anderen Prozessen rekonstruieren können. Die Gegenmaßnahmen (Kernel Page Table Isolation, Retpoline) verringern die Leistung um 5 bis 30 Prozent, je nach Workload.
Die Komplexität moderner Betriebssysteme ist erheblich. Der Linux-Kernel umfasst über 30 Millionen Zeilen Code (Stand 2025). Diese Größe macht formale Verifikation (den mathematischen Beweis der Korrektheit) für den gesamten Kernel praktisch unmöglich. Das Projekt seL4 hat einen formal verifizierten Microkernel mit etwa 10.000 Zeilen Code entwickelt. Der Aufwand dafür betrug über 20 Personenjahre.
Beispiel: Ein Treiber für eine neue Grafikkarte enthält einen Speicherfehler. In einem monolithischen Kernel führt dieser Fehler zu einem Systemabsturz (Kernel Panic unter Linux, Bluescreen unter Windows). In einem Microkernel-System wäre der Schaden auf den Grafiktreiber-Prozess begrenzt. Allerdings verwenden die meisten verbreiteten Betriebssysteme monolithische oder hybride Kernel.
Fachliche Einordnung: Betriebssysteme bilden die unterste Softwareschicht oberhalb der Hardware. Ihre Konzepte (Prozessisolation, virtueller Speicher, Dateisysteme, Zugriffssteuerung) sind Voraussetzung für das Verständnis von Systemsicherheit, verteilten Systemen und Cloud-Infrastruktur. Wer die Abstraktionen des Betriebssystems nicht kennt, kann Leistungsprobleme und Sicherheitslücken in darauf aufbauenden Systemen nicht einordnen.