Betriebssystemtheorie/ Einleitung

Hoch zum Inhaltsverzeichnis | Vor zu Hardware-Funktionen für das Betriebssystem

Definition - Was ist ein Betriebssystem?

Das Betriebssystem zwischen Hardware und Anwendungen

Ein Betriebssystem ist eine Sammlung von Programmen und Bibliotheken, die die Hardware des Computers verwalten und für Anwendungsprogramme nutzbar machen. Darüber hinaus steuert und überwacht ein Betriebssystem den Ablauf von Programmen.

Der wichtigste Teil eines Betriebssystems ist der Kernel. Er wird beim Boot-Vorgang in den Arbeitsspeicher geladen und bleibt dort, solange das Betriebssystem genutzt wird. Andere (Teil-)Programme werden bei Bedarf in den Arbeitsspeicher geladen, z.B. Kommandos oder Hilfsprogramme. Dazu gehören auch CLIs (Command Line Interface) oder GUIs (Graphical User Interface). Die Bibliotheken, auch API (Application Programming Interface) genannt, stellen die Funktionen des Betriebssystems Anwenderprogrammen zur Verfügung. Daraus ergibt sich ein Schichtenmodell: Unten die Hardware, dazwischen das Betriebssystem und darüber die eigentlichen Anwendungsprogramme.

Auch das Betriebssystem selbst kann man nochmals in Schichten unterteilen: Unten der Kernel mit den absolut grundlegenden Diensten wie der Speicherverwaltung, darüber die API um die Funktionalität des Kernels aus anderen Programmen heraus nutzen zu können und darauf aufbauend zum Schluss die Shells, Kommandos und Anwendungsprogramme.

Generell kann man unterscheiden zwischen Single-User- und Multi-User- sowie zwischen Single-Process- und Multi-Process-Betriebssystemen. Single-User-Betriebssysteme kennen nur einen einzigen Benutzer im System, bzw. gar keinen, da bei solchen Systemen eine Benutzerverwaltung meist gar nicht vorgesehen ist. Multi-User-Systeme dagegen kennen mehrere Benutzer im System, die teilweise auch gleichzeitig auf derselben Maschine arbeiten können.

Single-Process-Systeme können lediglich einen Prozess zur gleichen Zeit ausführen. Multi-Prozess-Systeme dagegen erlauben die Ausführung fast beliebig vieler Prozesse parallel oder quasi-parallel. Ein typisches Beispiel für ein Single-User-/Single-Prozess-Betriebssystem ist DOS. Praktisch alle modernen Betriebssysteme sind Multi-User-/Multi-Process-Betriebssysteme, Ausnahmen bilden hierbei teilweise Betriebssysteme für Mobiltelefone und andere eingebettete Systeme.

Wir werden uns im Rahmen dieses Buches nur mit Multi-User-/Multi-Prozess-Betriebssystemen wie sie auf den meisten PCs und Servern zu finden sind, befassen.

Glossar

• CLI (Command Line Interface) - zu deutsch Kommandozeile, auch als Terminal oder Konsole bezeichnet, ist eine Schnittstelle zur Interaktion mit dem Betriebssystem in Textform. Siehe auch: Kommandozeile.
• GUI (Graphical User Interface) - zu deutsch "Grafische Benutzeroberfläche". Die Kommunikation mit dem Betriebssystem erfolgt hier meist über grafische Symbole, die Steuerung erfolgt meist mit der Maus. Siehe auch: Grafische Benutzeroberfläche.
• API (Application Programming Interface) - eine Schnittstelle, die von einem Softwaresystem anderen Programmen zur Anbindung an das System zur Verfügung gestellt wird. Siehe auch: API
• Shell - (engl. für Hülle, Schale, hier im Sinne von Oberfläche). Als Shell bezeichnet man häufig die Kommandozeile eines Betriebssystems, obwohl das nicht ganz richtig ist. Eine Shell ist die Oberfläche, über die ein Benutzer sein Betriebssystem bedienen kann. Das kann eine Kommandozeile sein, jedoch auch eine GUI. Siehe auch: Shell

Allgemeine Aufgaben von Betriebssystemen

Die Aufgaben eines Betriebssystems bestehen hauptsächlich in der Abstraktion von den Details der Hardware, der Verwaltung von Ressourcen sowie dem Schutz von gleichzeitig laufenden Anwendungen voreinander.

Die Abstraktion von den Details der Hardware ist der Aufgabenbereich des Betriebssystems, den man als Anwender am stärksten bemerkt. Wenn man sich zum Beispiel die Dateien auf einem Datenträger anzeigen lässt, werden hier bereits die verschiedenen Protokolle zu den Laufwerksschnittstellen, die Steuerkommandos und die Rohdaten aus den Datenblöcken des Datenträgers vom Anwender unbemerkt verarbeitet, um dann auf die gewohnte Weise angezeigt zu werden.

Auch wenn man als Programmierer in eine Datei schreiben oder aus ihr lesen möchte, sorgt das Betriebssystem dafür, dass über API-Aufrufe wie OPEN, READ, WRITE und CLOSE recht komfortabel Dateien angelegt, gelesen und geschrieben werden können. Das Betriebssystem kümmert sich dann darum, ob das Gerät, auf dem gearbeitet wird, eine Festplatte ist, ob ein USB-Stick verwendet wird oder ob Steuersignale für ein ganz anderes Gerät erzeugt werden müssen.

Wenn mehrere laufende Programme gleichzeitig mit Dateien arbeiten, bekomme man ziemlich schnell das Problem, dass zwei Programme gleichzeitig auf den selben Datenträger zugreifen wollen. Würde den Programmen hier freie Hand gelassen, würde es zu einem Chaos kommen, da vielleicht Programm A die Daten bekommt, die Programm B angefordert hatte. Um so etwas zu verhindern, lässt man die Hardware-Ressourcen vom Betriebssystem verwalten. Nur das Betriebssystem hat direkten Hardwarezugriff, die Anwendungen können lediglich mit dessen Hilfe auf Hardwaregeräte zugreifen bzw. das Betriebssystem beauftragen, die Daten zu beschaffen.

Die Ressourcenverwaltung umfasst auch die Prozessorzeit, die Anwendungen zur Verfügung gestellt wird, und Arbeitsspeicher. Beim Arbeitsspeicher gibt es jedoch noch ein paar mehr Schwierigkeiten. Da immer auch Teile des Betriebssystems im Arbeitsspeicher liegen, eventuell auch noch andere Programme, muss sichergestellt werden, dass kein Programm Speicher überschreibt, der ihm nicht gehört, weder beabsichtigt noch unbeabsichtigt. Das könnte sonst zum Absturz des gesamten Systems führen. Jedes moderne Betriebssystem fängt diese ungültigen Zugriffe ab und beendet das entsprechende Programm in der Regel. Das sind dann die berüchtigten Zugriffsverletzungen, die dem Einen oder Anderen bereits begegnet sein dürften.

Das Prozess-Modell

Ein Betriebssystem arbeitet grundsätzlich mit Prozessen. Daraus ergibt sich die Frage, was einen Prozess von einem Programm unterscheidet.

Die Lösung:

• Ein Programm ist das, was auf dem Datenträger liegt und darauf wartet, gestartet zu werden.
• Ein Prozess ist eine Instanz eines Programmes, die sich im Arbeitsspeicher befindet, inklusive ihrer Arbeitsdaten.

Aus Sicht des Kernels ist ein Prozess eine Einheit, die sich in einem (virtuellen) Adressraum befindet. Sie besteht aus den Anweisungen des Programms, den zu verarbeitenden Daten und dem Stand der Abarbeitung. Dieser wiederum entspricht den Zuständen der Prozessorregister, soweit sie den Prozess betreffen. Jeder Prozess kann nur auf seinen eigenen Adressraum zugreifen.

Multi-User- / Multi-Process-Betriebssysteme

Multi-User- / Multi-Process-Betriebssysteme müssen einige grundlegende Anforderungen erfüllen. Sie müssen dafür sorgen, dass Prozesse nebeneinander ausgeführt werden können, ohne sich jedoch gegenseitig zu beeinflussen.

Das nebeneinander ausführen von Prozessen bedeutet vor allem, dass diese Prozesse dieselben Ressourcen benutzen. Sie liegen z.B. alle im selben Arbeitsspeicher (wenn auch an unterschiedlichen Stellen), bekommen Eingaben von der selben Tastatur, geben Daten auf den selben Bildschirm aus.

Dabei dürfen die Prozesse sich jedoch nicht gegenseitig beeinflussen. Dafür setzt ein entsprechendes Betriebssystem verschiedene Strategien und Mittel ein, die im späteren Verlauf des Buches noch genauer unter die Lupe genommen werden, hier jedoch schon mal eine kurze Übersicht:

Scheduling

Das Betriebssystem weisst bestimmte Ressourcen für eine kurze Zeit einem Prozess zur alleinigen Verfügung zu. Zum Beispiel wird ein Prozessor für eine kurze Zeit einem Prozess zugewiesen, damit er weiter ausgeführt werden kann, dann bekommt er den Prozessor wieder entzogen und pausiert, während ein anderer Prozess auf der CPU weiterarbeiten kann.

Getrennte Adressräume

Jeder Prozess bekommt einen eigenen Adressraum zugewiesen. Für den Prozess sieht es so aus, als gäbe es nur ihn im Speicher und als würde ihm aller Speicher des Computers gehören. Dadurch wird eine ungewollte Beeinflussung der Prozesse im Speicher unmöglich.

Das Betriebssystem setzt diese virtuellen Adressen, die der Prozess sieht und benutzt, auf echte Adressen um und verteilt die Prozesse im zur Verfügung stehen Arbeitsspeicher. Bei Speichermangel lagert es den Prozess vielleicht sogar kurzfristig auf die Festplatte aus, ohne dass dieser etwas davon merkt.

Zuordnung von Prozesse und Dateien zu Usern

Auf einer höheren Ebene kann das Betriebssystem Dateien und Prozesse Usern zuordnen. Damit kann festgelegt werden, was ein Prozess darf oder nicht darf, welche Priorität er bei der Zuteilung von Ressourcen bekommt und je nach System lässt sich die von einem User verbrauchte Rechenzeit abrechnen.

User-Authentifizierung

Um einer Userverwaltung eine vernünftige Basis zu geben, muss das Betriebssystem in der Lage sein, einen User zweifelsfrei zu authentifizieren. Dass das mit dem zweifelsfrei so eine Sache ist, zeigen jedoch immer mal wieder erfolgreiche Hacker-Angriffe, dann dabei geht es letztendlich genau darum, sich gegenüber dem Betriebssystem als ein User mit möglichst weitreichenden Rechten auszugeben. Um diese Rechte unterscheiden zu können benutzt die Benutzerverwaltung so genannte Rollenmodelle zur Unterscheidung der Benutzerrechte. Aktuelle Betriebssysteme verfügen in der Regel über mindestens zwei Rollenmodelle für die Benutzer. Die "normalen" Benutzer und privilegierte Benutzer, die Veränderungen an bestimmten Systemeinstellungen vornehmen dürfen. Ein Benutzer kann dabei die privilegierten Benutzerrechte während der Laufzeit anfordern, wenn ihm vorher diese Benutzerrolle als Option zugewiesen wurde. Beim Anmelden des Benutzers vergibt das System grundsätzlich nur die normalen Rechte an den Benutzer. Um privilegierte Benutzerrechte zu erlangen, muss der Benutzer sich ein zweites Mal authentisieren. Dadurch wird verhindert, dass bereits laufende Benutzerprozesse von Angreifern missbraucht und unzulässige Veränderungen am System vorgenommen werden.

Hardwareunterstützung für das Betriebssystem

Damit ein Betriebssystem die oben genannten Anforderungen erfüllen kann, benötigt es Unterstützung durch die Hardware. Da auf einem einzelnen Prozessor nur ENTWEDER das Betriebssystem ODER der Nutzerprozess laufen kann, muss die Hardware des Computers in der Lage sein, die Operationen des Nutzerprozesses z.B. auf die Verwendung gültiger Speicherbereiche zu überprüfen und notfalls das Betriebssystem zu aktivieren, damit es dem Treiben ein Ende setzt. Dafür benötigt ein entsprechender Prozessor eine recht komplexe Speicherverwaltungseinheit.

Für das Scheduling von Prozessen wird ebenfalls etwas Hardwareunterstützung in Form eines Timers benötigt, der periodisch das Betriebssystem "weckt", damit es gegebenenfalls einen Prozesswechsel durchführen kann. Ohne so einen Timer kann man zwar auch ein Multiprozess-Betriebssystem realisieren, allerdings müsste ein Prozess hier "freiwillig" den Prozessor freigeben. Das widerspräche dem Grundsatz, dass Prozesse sich nicht gegenseitig beeinflussen dürfen.

Kernel-Architekturen

Bei den Kernel-Architekturen gibt es im Wesentlichen zwei Ansätze, den monolithischen Kernel und den Mikrokernel, sowie Mischformen wie modulare monolithische Kernel.

Monolithische Kernel

Monolithische Kernel fassen den gesamten Code für alle Aufgaben des Systems in einem einzigen Block zusammen, daher auch der Name. Das macht ihn verhältnismäßig groß und unflexibel, was Änderungen angeht. Aber auch schnell, da alle Teilbereiche nur einen Sprungbefehl weit entfernt sind und keine Inter-Prozess-Kommunikation für Kernelaufgaben benötigt wird. Das Design eines Monolithen fällt meist leichter als das eines Mikrokernels, da man die Schnittstellen von Programmmodulen direkt aufeinander anpassen kann.

Mikrokernel

Mikrokernel zeichnen sich vor allem dadurch aus, dass sie klein sind, teilweise umfassen die Quellcodes weniger als 15000 Zeilen (gegenüber Monolithen, die einige Millionen Zeilen umfassen können). Der Mikrokernel erfüllt meist nur absolut grundlegende Dienste, wie die Speicherverwaltung, das Scheduling und die hier absolut notwendige Inter-Prozess-Komunikation (IPC - Inter-Process-Comunication). Er baut auf eine Client-Server-Architektur auf. Treibermodule lassen sich als Server beim Kernel registrieren und bieten ihre Dienste den Anwendungsprogrammen an.

Dadurch wird dieser Kerneltyp extrem flexibel. Server lassen sich jederzeit nachladen, oder entfernen. Auch der Neustart von Modulen ist möglich, ohne dass das System neu gestartet werden müsste. Das Interessanteste aus Sicherheitsaspekten ist jedoch, dass die Kernel-Module meist mit den gleichen Berechtigungen wie ganz normale User-Programme ausgeführt werden. Amok laufende Module können damit den Rest des System kaum gefährden, wogegen ein monolithischer Kernel, der komplett mit allen Systemrechten Amok läuft, fatal sein kann.

Dadurch gelten Systeme mit Mikrokerneln als sehr stabil. Jedoch auch als relativ langsam, da die IPC einen Overhead bei Systemaufrufen verursacht.

Hybridkernel

Hybridkernel versuchen das beste aus den Entwurfsmustern beider oben genannten Kerneltypen zu vereinen. Die ursprüngliche Version 3.1 von Windows NT war ein Mikrokern. Da es allerdings vergleichsweise langsam lief, entschloss sich Microsoft dazu, einige Betriebssystemdienste vom Benutzermodus in den Kernmodus zu verlegen. Mit der Zeit wurde das System immer mehr zum Monolithen.

Den gegenteiligen Ansatz findet man bei dem modernen Linux-Kernel. Dieser ist von seiner Grundstruktur und seiner Entwicklungsgeschichte her ein Monolith, jedoch um ein flexibles Modulsystem erweitert, dass Module während des laufenden Betriebs nachladen, beenden oder neu starten kann.