Inhaltsverzeichnis

Motivation   vii

Kurzfassung   x

Abstract   xi

1  Grundlagen  1

1.1  Linux-Kernel  1

1.1.1  Einleitung  1

1.1.2  Aufbau und Funktionsweise des monolithischen Kernels  3

1.2  Prozessmanagement  9

1.2.1  Prozesse vs. Threads  9

1.2.2  Erstellen Beenden von Prozessen  11

1.2.3  Prozesszust ande  13

1.2.4  User- Kernelmode  13

1.2.5  Interrupts  14

1.3  Speichermanagement  16

1.3.1  Speicheradressierung  16

1.3.2  Paging  18

1.4  I/O  20

1.4.1  Hardwareschichten  20

1.4.2  Softwareschichten  23

1.5  Virtual Machines  26

1.5.1  Techniken  26

1.5.2  Virtual Machine Monitor  28

1.5.3  CPUs mit Virtualisierungstechnologien  28

2  UML Theorie  30

2.1  Architektur  30

2.1.1  Aufbau  30

2.1.2  Systemcalls  31

2.1.3  Traps  33

iv

INHALTSVERZEICHNIS v

2.2  Managmentkonsole  34

2.2.1  Aufbau  34

2.3  Ausf uhrungsmodi  35

2.3.1  tt-Modus  36

2.3.2  Skas3-Modus  38

2.3.3  Skas0-Modus  41

2.4  Speichermanagement  42

2.4.1  Hauptspeicher  42

2.4.2  Filesysteme  43

2.4.3  hostfs  45

2.4.4  humfs  46

2.5  Security  48

2.5.1  Ausbruchsm oglichkeiten  48

2.5.2  Chroot  49

2.5.3  Ausbruch aus einem UML-Jail  49

3  UML-Praxis - Ausbruchsm oglichkeiten  51

3.1  Ausbruch durch das Filesystem  51

3.1.1  Vorgehensweise  52

3.1.2  Abwehr  53

3.2  Kernelmodul  53

3.2.1  Idee  54

3.2.2  Charakteristik von Modulen  54

3.2.3  Funktion  55

3.2.4  Modulerstellung  56

3.3  UML-Hauptspeicher  58

3.3.1  Idee  58

3.3.2  Ablauf  58

3.4  Systemcallhacking  59

3.4.1  lcall  60

3.4.2  ptrace  60

3.5  Shellcodeinjection  63

3.5.1  Vorgehensweise  63

3.5.2  Aufbau  64

3.5.3  Einschleusung  64

4  Fazit und Ausblick  66

5  Glossar  69

A  Zusatzinformation  72

A.1  UML-Theorie  72

A.1.1  Sysrq-Kommandos  72

A  1 2 Terminal I/O  72

INHALTSVERZEICHNIS vi

A.1.3  tmpfs-Performancetest  73

Literaturverzeichnis   

Motivation

User-Mode-Linux, abgek¨ urzt als UML ¹ , wurde von Jeff Dike im Jahre 1999 entwickelt. Es handelt sich dabei um ein Produkt aus der Virtualisierung. Der Wunsch, Betriebssysteme unabh¨ angig innerhalb anderer Betriebssysteme zu betreiben, wurde mit UML auf einem bisher noch nicht existierenden L¨ osungsweg realisiert. Bisher musste, unabh¨ angig von der eingesetzten Technologie, eine Zwischenschicht die Trennung der Betriebssysteme vornehmen. Die UML-Architektur ist so konstruiert, dass auf einen performancelastigen Layer verzichtet werden kann. Damit dieses Konzept auch auf existierende Betriebssysteme umgesetzt werden kann, ist hier schon eine erste Einschr¨ ankung zu sehen. UML unterst¨ utzt lediglich Linux-Betriebssysteme. UML kann von zwei unterschiedlichen Standpunkten analysiert und beurteilt werden. Die h¨ aufig vorkommende Feststellung ” UML ist ein Betriebssystem, das wie ein Programm auf einem Betriebssystem l¨ auft“ liefert schon eine grundlegende Definition von dem, was UML darstellt. Aus dem Betrachtungswinkel eines Benutzers am Hostsystem ist UML ein Benutzerprozess, auf den ersten Blick nicht vom Prozess einer anderen Anwendung zu unterscheiden. Aus anderem Betrachtungswinkel, dem des Benutzers innerhalb UML, ist UML ein vollwertiges Betriebssystem, das zun¨ achst nicht von einem Hostbetriebssystem unterscheidbar ist. Der ¨ Ubergang vom Betriebssystem zum Benutzerprogramm muss, da kein Virtualisierungslayer existiert, vom UML-Kernel ¨ ubernommen werden.

Um einen Linuxkernel zu einem UML-Linuxkernel umzufunktionieren, muss bei dessen ¨ Ubersetzung lediglich die eigens daf¨ ur entwickelte User-Mode-Architektur anstelle z.B. der x86 -Architektur verwendet werden. Zugriffe, die ein gew¨ ohnlicher Kernel an der Hardware durchf¨ uhrt, werden bei einem UML-Kernel durch die UML-Arch-Schnittstelle simuliert. Diese Schicht leitet die Anfragen an den Hostkernel als gew¨ ohnlicher Usermode-Prozess weiter.

Gerade durch diese transparente Architektur bietet UML interessante Einsatzgebiete.

¹ Nicht zu verwechseln mit der Abk¨ urzung f¨ ur ” Unified Modeling Language“, einer

standardisierten Sprache zur Modellierung von Systemen.

vii

MOTIVATION viii

Kernel- und Prozessdebugging

Der UML-Kernel kann vom Host aus mit denselben Tools debugged werden, wie es bei einem Benutzerprogramm m¨ oglich ist. Ebenso k¨ onnen UML- Benutzerprozessedebugged werden.

Lehre

UML eignet sich als virtuelles Betriebssystem hervorragend im Rahmen des Unterrichts. Studenten k¨ onnen an UML nicht nur die Funktionsweise und Eigenschaften von Betriebssystemen beobachten, sondern auch diese modifizieren, ohne dass die Gefahr besteht, Schaden am Hostbetriebssystem zu verursachen. Durch UML k¨ onnen auch andere Systemkomponenten, wie z.B. Gr¨ oße des Hauptspeichers oder die Anzahl der CPU-Kerne, unabh¨ angig vom realen Vorhandensein ausgew¨ ahlt werden.

Sandbox

Eine Sandbox schottet Prozesse, die in dieser betrieben werden, vom Rest des Systems ab. Prozesse, die innerhalb von UML laufen, erlangen, soweit es nicht gewollt ist, keinen Zugriff auf das Hostsystem. Anwendungen k¨ onnen somit keinen Schaden am Hostsystem anrichten. UML stellt selbst eine Sandbox dar und kann auch als Usermode-Programm, als Prozess des Hostsystems ebenso wie ein gew¨ ohnlicher Benutzerprozess in einer weiteren Sandbox betrieben werden, etwa durch Einsatz des ” chroot“-Systemcalls.

Prozesse, die innerhalb einer Sandbox laufen, besitzen keine M¨ oglichkeit, aus dieser Sandbox auszubrechen. Die Sandbox umfasst einen vom Benutzer definierten Bereich in der Verzeichnishierachie und im Hauptspeicher, der f¨ ur die eingeschlossenen Programme als gesamt verf¨ ugbarer Ressourcenbereich wirkt. Ausbr¨ uche in andere Verzeichnisse durch absolute Pfadnamen oder Befehle ² werden als gew¨ ohnliche Systemcalls an den Kernel, unter dem die Sandbox l¨ auft, gerichtet, welcher diese lediglich in den Speicherbereichen der Sandbox verarbeitet und einen Ausbruch verhindert.

Virtuelles Netzwerk

Auf einem Hostsystem k¨ onnen durchaus mehrere Instanzen betrieben werden, die durch ein simuliertes Netzwerk miteinander verbunden werden. Dies l¨ asst sich durch unterschiedliche Varianten realisieren. Ein daf¨ ur notwendiger Switch wird als eigenst¨ andiges Hostprogramm von UML zur Verf¨ ugung tap“-Schnittstellen ³ verbunden gestellt. Instanzen k¨ onnen mit ” tun“- oder ”

werden und somit eine Kommunikation zwischen weiteren UML-Instanzen

² z.B. ” ../“

³ Diese Schnittstellen sind simulierte Netzwerkschnittstellen, die durch einen VPN- Tunnel mit einer verbunden sind.

MOTIVATION ix

oder Systemen außerhalb des Hostsystems aufnehmen. Eine weitere M¨ oglichkeit beschr¨ ankt sich lediglich auf UML-Instanzen, wobei keine Schnittstellen vom Host zur Verf¨ ugung gestellt werden und eventuelle Gef¨ ahrdungen innerhalb des UML-Netzwerkes nicht das reale Netzwerk beeintr¨ achtigen. Der Vorteil von virtuellen Netzwerken liegt darin, dass die Kommunikation von mehreren Systemen ¨ uber das Netzwerk ohne Einschr¨ ankungen in der Funktionalit¨ at entwickelt und getestet werden kann, ohne zwei oder mehrere reale Systeme zu ben¨ otigen.

Kurzfassung

User-Mode-Linux ist eine Software, die sowohl in die Bereiche Benutzerprogramme, als auch Betriebssysteme zugeordnet werden kann. UML ist der Kategorie der Systemvirtualisierung zuzuordnen, dessen Funktionalit¨ at sich von weiteren Virtualiserungstechnologien stark unterscheidet. Eine UML- Instanzwird vom Benutzer in einem Hostsystem als Benutzerprogramm gestartet und ohne Root-Privilegien am Hostsystem ausgef¨ uhrt. UML verzichtet auf eine Virtualisierungsschicht. Die Architekturschnittstelle des UML- Kernelsist die einzige Komponente, die sich von herk¨ ommlichen Linuxkernel unterscheidet. Diese Schicht kommuniziert nicht mit der Hardware, sondern fordert Ressourcen vom Hostbetriebssystem als Benutzerprozess an. Diese Vorgehensweise beschr¨ ankt den Einsatz von UML auf Hostsystemen, die unter Linux betrieben werden.

Das erste Kapitel betrachtet die wesentlichen Komponenten eines Betriebssystems. Eingeleitet wird mit der Funktionsweise des Linuxkernels und die Differenzen der eingesetzten Architekturen. UML erzeugt f¨ ur eigene Zwecke Prozesse am Host, weshalb auch das Thema Prozessmanagement betrachtet wird. Ein weiterer Punkt ist das Speichermanagement, da UML als Betriebssystem Haupt- und Festplattenspeicher ben¨ otigt, der vom Host zur Verf¨ ugung gestellt werden muss. Abgeschlossen wird dieses Kapitel mit einem Exkurs in die Funktionsweise alternativer Virtualisierungstechnologien. Der Hauptteil umfasst die Funktionsweise und Eingliederung von UML auf einem Hostsystem. Es existieren unterschiedliche Varianten, wie UML am Host betrieben werden kann, weshalb deren Funktionsweisen analyisiert werden. Behandelt wird auch die Virtualisierung von Ressourcen durch UML.

Im letzten Kapitel werden die Sicherheitsaspekte von UML untersucht. M¨ oglichkeiten, die einem Benutzer den Ausbruch aus UML auf das Hostsystem erm¨ oglichen, werden aus unterschiedlichen Blickwinkeln erkl¨ art, sowie M¨ oglichkeiten, um Ausbr¨ uche zu verhindern. Abschließend werden Einsatzgebiete er¨ ortert, deren Erschließung durch UML in Zukunft geplant ist.

x

Abstract

The software User-Mode-Linux can be treaten from two different points of view. On the one side it is a user program and on the other hand it is an operating system. UML is part of the domain of system virtualization, but with the addition that its functionality differs from existing technologies. This system is started up by the user on a host system, just like a user program without root privileges. UML is executed without a virtualization layer. The architecture layer is the only modified part of the UML kernel which differs from common linux kernels. The major difference of this layer is the destination of communication. Requests generated by UML processes are not sent to the hardware, they are sent to the host kernel like a host user process. This modus operandi uniques the usability on linux host systems. The first chapter covers fundamental components of an operating system beginning with the mode of operation of the Linux kernel and discrepancies of appointed architectures. Processes will be created on the host for own purposes by UML and thus process management will be deconstructed. The memory management will be also analyzed because UML as an operating system needs main memory and disk storage provided by the host. This chapter will be completed with an excursus describing the functionality of alternative virtualization technolgies.

The major part of this thesis covers functionality and integration of UML into a host system. Executing UML on a host can be implemented in the form of different models. Each model will be specified and qualified. Another section is the description how resources will be virtualized by UML. In the last chapter of this thesis, procedures how a UML user can break out of UML and gain access to the host system are analyzed. To prevent break outs, counter measures will be explicated to protect the host against these attacks.

xi

Kapitel 1

Grundlagen

1.1 Linux-Kernel

Der Kernel ist das Zentrum eines jeden Betriebssystems. Situiert ist der Kernel als Schicht zwischen Hardwareressourcen und Anwendungsprogrammen. Die durch die Hardware des Computers zur Verf¨ ugung gestellten Ressourcen befinden sich im alleinigen Zugriff durch den Kernel. Diese Tatsache stellt die Grundlage f¨ ur den gleichzeitigen Betrieb mehrerer Anwendungsprogramme dar. Programme ben¨ otigen, um ausgef¨ uhrt zu werden, zur Laufzeit Rechenzeit und Ressourcen aus der Hardwareschicht. Wie schon erw¨ ahnt, kann nur der Kernel auf die Hardware zugreifen. Deshalb m¨ ussen Programme, um Ressourcen zugewiesen zu werden, Anfragen, wie z.B. das Lesen einer bestimmten Datei von der Festplatte, an den Kernel stellen, welcher diesen Auftrag ausf¨ uhrt und das Ergebnis zur¨ uckliefert. Der Kernel stellt nicht nur Ressourcen zur Verf¨ ugung, sondern auch Rechenzeit, die ein Programm ben¨ otigt, um ausgef¨ uhrt zu werden.

1.1.1 Einleitung

Am Markt existieren unterschiedliche Betriebssysteme, wie etwa ” Microsoft Windows“, ” Unix“, ” Linux“ oder ” OS/2“, um nur einige zu nennen.

Demnach besitzen unterschiedliche Betriebssysteme auch unterschiedliche Kernel, deren Architekturen sich untereinander differenzieren.

Exokernel

Bei dieser Architektur werden Kernelfunktionalit¨ aten, die in anderen Architekturen vom Kernel wahrgenommen werden, von den Anwendungsprogrammen wahrgenommen, die diese als Bibliothek beinhalten. Der Kernel selbst ¨ ubernimmt nur die Ressourcenverwaltung. Der Vorteil dieser Architektur liegt in der Erweiterung, da diese an den Anwendungsprogrammen selbst und individuell f¨ ur ihre Einsatzzwecke vorgenommen werden k¨ onnen.

1

KAPITEL 1. GRUNDLAGEN 2

Nachteilig ist jedoch, dass Programme Aufgaben, wie die Verwaltung von Plattenbl¨ ocken durch eigene Dateisysteme oder z.B. Netzwerksockets, selbstst¨ andig implementieren m¨ ussen. Diese Art der Implementierung weist keine Sicherheitsl¨ ucken auf, da die Anwendungsprogramme mit ihren Betriebssystemfunktionen im Usermode ¹ betrieben werden [12, S.19]. Der Exokernel existiert in drei unterschiedlichen Implementationen ² , die auf der Exokernelarchitektur basieren. Diese Implementationen unterscheiden sich anhand der eingesetzten Hardware. ”

unter ” DECstations und MIPS-Prozessoren, ” SPARC“-basierte Multiprozessormaschinen und ”

mentation, kann auf Systemen mit ” x86“-Prozessoren eingesetzt werden [17, S.12].

Mikrokernel

Der Mikrokernel beherbergt ausschließlich Funktionalit¨ aten wie ” Message Passing“, ” Virtual Memory“, ” Scheduling“ und ” Ger¨ atetreiber“. Zus¨ atzliche Funktionen sind in Serverprozessen enthalten, die im Benutzermodus ausgef¨ uhrt werden. Serverprozesse unterscheiden sich nicht von gew¨ ohnlichen Benutzerprozessen. Diese befinden sich im Usermode und stellen Funktionen, die nicht im Kernel enthalten sind, zur Verf¨ ugung. Der Grund f¨ ur die Ausf¨ uhrung der zus¨ atzlichen Funktionen liegt in der Gew¨ ahrleistung der Sicherheit zum Einem als Schutz vor Manipulationen und zum Anderen durch die Einschr¨ ankung der Auswirkungen von Fehlern auf den verursachenden Serverprozess. Der Kern ist das einzige Medium, welches auf die Hardwareressourcen zugreifen darf. Anforderungen an Hardwareressourcen durch ein Anwendungsprogramm werden an den Kernel gerichtet, welcher diese an den zust¨ andigen Serverprozess weiterleitet und die Antwort ¨ uber den Mikrokernel an die Applikation zur¨ uckliefert. Der Vorteil in diesem Client/Server-Modell liegt bei dem Einsatz in verteilten Betriebssystemen, da Serverprozesse nicht nur lokal vorhanden sein m¨ ussen und somit diese Ressourcen nicht redundant zu Lasten der Performance ausgelegt werden m¨ ussen.

Monolithischer Kernel

Der monolithische Kernel beinhaltet im Gegensatz zu anderen Architekturen alle f¨ ur die Ausf¨ uhrung eines Betriebssystems erforderlichen Funktionen. Es m¨ ussen somit keine Funktionen durch Benutzerprogramme aus dem Usermode bereitgestellt werden. Der Kernel beinhaltet s¨ amtliche Treiber, die f¨ ur den Betrieb erforderlich sind. Der Nachteil liegt zum Einen darin, dass

¹ Wird im Abschnitt 1.2.4 erl¨ autert.

² Das Betriebssystem ” ExOS“, welches auf ” UNIX“ basiert, setzt die Kernel ” Aegis“

und ” Xok“ ein.

KAPITEL 1. GRUNDLAGEN 3

fehlerhafte Treiber auch den restlichen Kernel kompromittieren k¨ onnen. Ein weiterer Nachteil besteht darin, dass ein sp¨ ateres Hinzuf¨ ugen oder Entfernen des Treibers eine Neukompilierung aus den Sourcen erfordert ³ . Eine modifizierte Variante dieser Kernelarchitektur wird unter Linux eingesetzt. Die Modifikation besteht darin, dass Treiber zur Laufzeit in Form von Modulen an den Treiber gebunden und wieder entfernt werden k¨ onnen. Diese Module werden im Kernelmode betrieben. Fehlerhafte Module wirken sich durch dieses Modell negativ auf den gesamten Kern aus, da diese auf den gesamten Kerneladressraum uneingeschr¨ ankte Rechte besitzen. Diese Variante erm¨ oglicht jedoch, dass eine Neukompilierung des Kernels umgangen werden kann. Der wesentlichste Vorteil in dieser Kernelarchitektur liegt in der zum Vergleich anderer Technologien hohen Performance, da s¨ amtliche Funktionen im Kernelmode ausgef¨ uhrt werden und deren Kommunikation, die vollst¨ andig im Kernelmode ausgef¨ uhrt wird, keine zus¨ atzliche Interprozesskommunikation aufw¨ anden muss.

Makrokernel

Der Makrokernel ⁴ stellt eine Kombination aus Mikro- und monolithischem Kernel dar ⁵ . Im Vergleich zum Mikrokernel besitzt dieser mehrere Funktionen, die sich somit im Kernelmode befinden, womit ein Geschwindigkeits-vorteil gegen¨ uber dem Mikrokernel erzielt werden kann, da weniger Kontextwechsel erforderlich sind [25]. Dieser Kernel verf¨ ugt jedoch nicht ¨ uber den

Funktionsumfang eines monolithischen Kernels. Beim Makrokernel werden nicht alle Treiber im Kernelmode betrieben und somit das Risiko reduziert, dass bei einem fehlerhaften Usermodetreiber der gesamte Kernel abst¨ urzt. Eine Regel, die besagt, welche Funktionen im Kernel vorhanden sind und welche extern im Usermode betrieben werden, existiert nicht.

1.1.2 Aufbau und Funktionsweise des monolithischen Kernels

Die Abbildung 1.1 zeigt den Aufbau und das Zusammenwirken der in einem Kernel enthaltenen Bestandteile bei monolithischer Kernelarchitektur.

Prozessverwaltung

Dieser Teil des Kernels erm¨ oglicht es, einen oder mehrere Prozesse ⁶ auf einer CPU auszuf¨ uhren. Pro vorhandenen CPU-Kern kann immer nur ein Prozess

³ Es nicht m¨ oglich, Treiber direkt in die Bin¨ ardatei des Kernels zu kopieren.

⁴ Wird auch als Hybridkernel bezeichnet.

⁵ Diese Kerneltechnologie wurde unter Windows NT 4.0 eingesetzt.

⁶ Der Linuxkernel in der aktuellen Version 2.6 unterst¨ utzt den Betrieb von mehreren Prozessen gleichzeitig.

KAPITEL 1. GRUNDLAGEN

gleichzeitig ausgef¨ uhrt werden. Jedoch findet ein Prozesswechsel durch den Kernel in sehr kurzen Zeitabst¨ anden statt, sodass dies dem Benutzer durch seine tr¨ ageren Sinnesorgane als Parallelbetrieb erscheint. Verf¨ ugt ein System uber mehrere CPU-Kerne, so k¨ onnen der Zahl der Kerne entsprechend gleich ¨

viele Prozesse gleichzeitig abgearbeitet werden. Der Aufgabenbereich des Kernels liegt in der Erstellung und der Beendigung von Prozessen, der Kommunikation zwischen Prozessen untereinander, durch Signale und Pipes sowie dem Scheduling ⁷ von Prozessen. Der Aufbau und die Funktionsweise von Prozessen wird intensiver im Abschnitt 1.2 behandelt.

Die Prozessverwaltung beinhaltet auch die Prozesserzeugung durch das Betriebssystem, welche auf folgende Weise erzeugt werden kann. 1. Zuweisung einer eindeutigen Prozesskennung zum neuen Prozess. Der prim¨ aren Prozesstabelle wird ein neuer Eintrag hinzugef¨ ugt. 2. Zuteilung von Speicherplatz f¨ ur den Prozess. Beinhaltet alle Elemente des Prozessabbilds. Die von der Art des Prozesses abh¨ angige Gr¨ oße kann als Standardwert durch den Benutzer zum Zeitpunkt der Joberstellung oder durch den Elternprozess an den Kernel ¨ ubergeben werden, sofern dieser den Prozess erzeugt.

⁷ Algorithmus zur Auswahl eines Prozesses, welcher als n¨ achster l¨ auft [32, S.148]. Wird genauer unter Abschnitt 1.1.2 behandelt.

KAPITEL 1. GRUNDLAGEN 5

3. Initialisierung des Prozesskontrollblocks, welcher die ID des Prozesses, die ID des erzeugenden Prozesses und Prozessorstatusinformationen enth¨ alt, wobei bis auf ” ProgramCounter“ und Systemstapelzeiger die Eintr¨ age mit Standardwerten und Attributen versehen werden. Der Prozesszustand wird auf ” bereit“ gesetzt.

Eine weitere Aufgabe der Prozessverwaltung liegt im Wechsel von aktiven Prozessen. Der Prozesswechsel kann zu einem beliebigen Zeitpunkt erfolgen, der entweder durch einen ” Interrupt“, ” Trap“ oder ” Supervisor“-Aufruf eingeleitet wird.

Die Terminierung von Prozessen erfolgt in der Regel durch den Prozess selbst, in dem ein ” Interrupt“ an den Kernel gesendet wird. Die Terminierung eines Prozesses kann auch durch seinen Vaterprozess veranlasst werden oder durch das Betriebssystem selbst.

Ein weiteres Aufgabengebiet ist die Interprozesskommunikation, die der Kommunikation von Prozessen untereinander dient, da diese in unterschiedlichen Adressr¨ aumen liegen und somit keinen direkten Zugriff zueinander erlangen k¨ onnen. Die Prozessverwaltung ¨ ubernimmt auch die Verwaltung der Prozesskontrollbl¨ ocke. Ein Prozesskontrollblock enth¨ alt s¨ amtliche Informationen uber einen Prozess, die vom Betriebssystem f¨ ur die Steuerung des Prozesses ¨

ben¨ otigt werden. Diese Steuerinformationen sind unter [31, S.160] abgebildet.

Speicherverwaltung

Die Speicherverwaltung bezieht sich auf den Hauptspeicher eines Computersystems, da dieser zwischen Betriebssystem und den Prozessen des Systems aufgeteilt werden muss. Es wird zwischen virtuellen und physikalischen Adressr¨ aumen unterschieden. Der physikalische Adressraum lokalisiert den gesamten Hauptspeicher. Die einzelnen Speicherbereiche des Hauptspeichers sind verschiedenen Prozessen zugeordnet. Der virtuelle Adressraum existiert separat f¨ ur jeden Prozess. Dieser enth¨ alt die Adressen des eigenen Prozesses sowie die des Kernels.

Die Adressen des virtuellen Adressraumes referenzieren dabei auf Adressen des physikalischen Adressraums, deren Adressen unabh¨ angig von denen des virtuellen Adressraums sind. Virtuelle Adressr¨ aume erm¨ oglichen eine effizientere Ausnutzung des Hauptspeichers. Betriebssysteme, die die parallele Ausf¨ uhrung mehrerer Prozesse unterst¨ utzen, k¨ onnen den gesamten Prozess, aber auch Teile unterschiedlicher Prozesse im Hauptspeicher halten. Ein weiterer Vorteil ist, dass im Prozess keine Funktionen vorhanden sein m¨ ussen, die Codefragmente auf andere physikalische Datentr¨ ager wie etwa auf die Festplatte auslagern. Selbst wenn der Code an einer anderen Adresse im Hauptspeicher eingelagert wird, stellt dies kein Problem dar.

KAPITEL 1. GRUNDLAGEN 6

Der Kernel bietet Schutzfunktionen an, um zu vermeiden, dass Prozesse (un)gewollt auf Speicherbereiche im Hauptspeicher referenzieren, die zur Laufzeit von anderen Prozessen belegt sind. Eine weiterf¨ uhrende Erl¨ auterung findet sich im Abschnitt 1.3.1 wieder.

Dateisysteme

¨ Uber die Hardware des Systems legt der Kernel ein strukturiertes Dateisystem. Diese Datei-Abstraktion findet sich im gesamten Betriebssystem wieder. Linux unterst¨ utzt unterschiedliche Dateisysteme. F¨ ur blockorientierte Ger¨ ate, wie z.B. die Festplatte, werden Systeme wie ext3, reiserfs, oder auch fat verwendet. Informationen ¨ uber Kernelkonfigurationen sowie die Systemzust¨ ande werden durch das in Linux vorhandene proc-Datei- systemin Dateien dargestellt.

Ger¨ atesteuerung

Jedem Betriebssystem unterliegen Hardwarekomponenten, sei es in realer oder virtualisierter Form. Die Ausf¨ uhrung des Betriebssystems und der Bedarf von Ressourcen durch Programme, wie z.B. das Lesen von Tastatureingaben, verlangen vom Betriebssystem eine Steuerung dieser Komponenten. Ein System besteht aus unterschiedlichen Hardwarekomponenten, die eigenst¨ andige Aufgaben ¨ ubernehmen und daher unterschiedlich bedient wer-

den m¨ ussen. Die Tatsache, dass eine Vielzahl an unterschiedlichen Hardwarekomponenten existieren, l¨ asst darauf schließen, dass Ger¨ atetreiber großteils vom Hersteller entwickelt werden. Die Funktionsweise von Treibern werden im Abschnitt 1.4.2 intensiver erl¨ autert.

Netzwerkbetrieb

Neben Block- und Zeichenger¨ atetreiber existieren auch Netzwerkger¨ atetreiber im Linuxkernel. Diese Treiber steuern die Netzwerkschnittstellen eines Computers. Neben den physischen Netzwerkkarten wird auch eine virtuelle Netzwerkkarte ⁸ angesteuert, die vom Kernel simuliert wird. Der Grund f¨ ur die Existenz einer solchen Softwareschnittstelle liegt darin, dass Prozesse auch die Netzwerkschicht zur Kommunikation untereinander verwenden k¨ onnen.

Ein erster Unterschied zu Block- und Zeichenger¨ aten liegt darin, dass Netzwerkschnittstellen nicht in Form einer Datei im Betriebssystem repr¨ asentiert werden, wie das bei einer Festplatte mit beispielsweise ” /dev/hda1“ der

Fall ist. Ein zweiter Unterschied im Gegensatz zum Blocktreiber liegt darin, dass dessen Ausf¨ uhrung nicht ausschließlich vom Linuxkernel initiiert wird,

⁸ Diese Device umfasst einen IP-Adressbereich von 127.0.0.1 bis 127.255.255.254 und kann alternativ ¨ uber ” localhost“ kontaktiert werden.

KAPITEL 1. GRUNDLAGEN 7

sondern dieser bei einkommenden Netzwerkpaketen dies dem Kernel durch Interrupts signalisieren muss. Diese Pakete der Netzwerkschicht des Kernels sind unabh¨ angig von den eingesetzten Netzwerkprotokollen ⁹ der Userprogramme sowie der darunter liegenden Hardwareprotokolle ¹⁰ . Programme, welche Netzwerkaktivit¨ aten verfolgen, m¨ ussen, um Netzwerkpakete senden und empfangen zu k¨ onnen, eine Verbindung zum Netzwerkkartentreiber aufbauen. Diese Verbindung wird auch als Socket bezeichnet. Eine Netzwerkschnittstelle kann eine Vielzahl von Sockets gleichzeitig aufweisen. Eine Applikation baut vor dem Senden von Informationen oder der Bereitschaft des Empfanges von Paketen eine Socketverbindung auf. Ein Socket kann jedoch nicht vom Kernel zu einem Benutzerprozess aufgebaut werden. Dieses ” Linux Netzwerk Subsystem“ ist in vier Schichten untergliedert [22, S.41].

Ein Prozess, welcher Daten als Netzwerkpakete sendet, muss den ” syssockcall“-Systemcall ausl¨ osen. Das Senden von Paketen durch Systemcalls ist der einzige Weg, damit Pakete ¨ uber eine Netzwerkschnittstelle in das

Socket-Interface transportiert werden k¨ onnen. Je nach dem zugrundeliegenden ¨ Ubertragungsprotokoll der Pakete wird die passende Socketimple- mentierungausgef¨ uhrt. Das ” Netdevice Interface“ als nachfolgende Schicht organisiert die zu sendenden Pakete durch Pufferung in einer Warteschlange, welche anschließend an den Treiber weitertransportiert werden. Diese Schicht bietet die M¨ oglichkeit, Datenpakete nach bestimmten Kriterien, wie verwendetes Protokoll oder Sender- und Empf¨ anger, zu filtern und diese in unterschiedliche Warteschlangen aufzuteilen. Diese Warteschlangen werden unterschiedlich oft abgerufen, womit ” Traffic Shaping“ erm¨ oglicht wird. Beim Empfang von Daten werden die Schichten in umgekehrter Reihenfolge ausgef¨ uhrt, wobei f¨ ur diese Pakete ein eigener Puffer existiert.

Die letzte Schicht beinhaltet die Ger¨ atetreiber f¨ ur Netzwerkschnittstellenkarten. Dieser Treiber implementiert die Steuerung der Netzwerkkarten. Die von der ” Netdevice“-Schicht empfangenen Pakete leitet der Treiber an die Schnittstellenkarte weiter, welche im finalen Schritt diese versendet. Empfangene Pakete werden vom Treiber entgegengenommen und in die Warteschlange des ” Netdevice-Interfaces“ weitergeleitet.

Scheduling

Wie im letzten Abschnitt erw¨ ahnt, kann immer nur ein Prozess pro CPU-Kern ausgef¨ uhrt werden. Diese Gegebenheit verlangt vom Kernel einen Mechanismus, welcher die CPU-Rechenzeit zwischen allen Prozessen verteilt. Dieser Mechanismus wird vom Scheduler ¨ ubernommen. Unterschieden

werden drei Arten des Schedulings, die in der Tabelle 1.1 aufgelistet sind.

⁹ z.B. IP, IPX.

¹⁰ z.B. Ethernet, Token-Ring, Fiber Distributed Data Interface (FDDI).