UML - User Mode Linux

Scharnböck, Christoph

UML - User Mode Linux

Ausbruch aus User Mode Linux

von Christoph Scharnböck (Autor:in)

Medien / Kommunikation - Medienökonomie, -management

Zusammenfassung

Inhaltsangabe:Die in der Arbeit erwähnte CD ist nicht Bestandteil des eBooks.

Zusammenfassung:
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ät sich von weiteren Virtualiserungstechnologien stark unterscheidet. Eine UML-Instanz wird vom Benutzer in einem Hostsystem als Benutzerprogramm gestartet und ohne Root-Privilegien am Hostsystem ausgeführt. UML verzichtet auf eine Virtualisierungsschicht. Die Architekturschnittstelle des UML-Kernels ist die einzige Komponente, die sich von herkömmlichen Linuxkernel unterscheidet. Diese Schicht kommuniziert nicht mit der Hardware, sondern fordert Ressourcen vom Hostbetriebssystem als Benutzerprozess an. Diese Vorgehensweise beschränkt 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ür 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ötigt, der vom Host zur Verfügung 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 analysiert werden. Behandelt wird auch die Virtualisierung von Ressourcen durch UML.
Im letzten Kapitel werden die Sicherheitsaspekte von UML untersucht. Möglichkeiten, die einem Benutzer den Ausbruch aus UML auf das Hostsystem ermöglichen, werden aus unterschiedlichen Blickwinkeln erklärt, sowie Möglichkeiten, um Ausbrüche zu verhindern. Abschließend werden Einsatzgebiete erörtert, deren Erschließung durch UML in Zukunft geplant ist. Inhaltsverzeichnis:Die in der Arbeit erwähnte CD ist nicht Bestandteil des eBooks. Inhaltsangabe kann bei info@diplom.de angefragt werden.

Inhaltsverzeichnis:
Motivationvii
Kurzfassungx
Abstractxi
1.Grundlagen1
1.1Linux-Kernel1
1.1.1Einleitung1
1.1.2Aufbau und Funktionsweise des monolithischen Kernels3
1.2Prozessmanagement9
1.2.1Prozesse vs. […]

Leseprobe

Inhaltsverzeichnis

Christoph Scharnböck

UML - User Mode Linux

Ausbruch aus User Mode Linux

ISBN: 978-3-8366-2987-4

Herstellung: Diplomica® Verlag GmbH, Hamburg, 2009

Zugl. Fachhochschule Hagenberg, Hagenberg, Österreich, Bachelorarbeit, 2007

Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,

insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von

Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der

Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,

bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung

dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen

der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik

Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich

vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des

Urheberrechtes.

Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in

diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,

dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei

zu betrachten wären und daher von jedermann benutzt werden dürften.

Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können

Fehler nicht vollständig ausgeschlossen werden und der Verlag, die Autoren oder

Übersetzer übernehmen keine juristische Verantwortung oder irgendeine Haftung für evtl.

verbliebene fehlerhafte Angaben und deren Folgen.

http://www.diplomica.de, Hamburg 2009

Inhaltsverzeichnis

Motivation

vii

Kurzfassung

Abstract

1 Grundlagen

1.1 Linux-Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.1.1

Einleitung . . . . . . . . . . . . . . . . . . . . . . . . .

1.1.2

Aufbau und Funktionsweise des monolithischen Kernels

1.2 Prozessmanagement . . . . . . . . . . . . . . . . . . . . . . .

1.2.1

Prozesse vs. Threads . . . . . . . . . . . . . . . . . . .

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

2.1 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.1.1

Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.1.2

Systemcalls . . . . . . . . . . . . . . . . . . . . . . . . 31

2.1.3

Traps . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

INHALTSVERZEICHNIS

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

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

5 Glossar

A Zusatzinformation

A.1 UML-Theorie . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

A.1.1 Sysrq-Kommandos . . . . . . . . . . . . . . . . . . . . 72

A.1.2 Terminal I/O . . . . . . . . . . . . . . . . . . . . . . . 72

INHALTSVERZEICHNIS

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 Betriebssys-

teme 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 vorneh-

men. Die UML-Architektur ist so konstruiert, dass auf einen performance-

lastigen Layer verzichtet werden kann. Damit dieses Konzept auch auf exis-

tierende 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 be-

urteilt werden. Die h¨aufig vorkommende Feststellung

UML ist ein Be-

triebssystem, 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 Benutzer-

prozess, auf den ersten Blick nicht vom Prozess einer anderen Anwendung

zu unterscheiden. Aus anderem Betrachtungswinkel, dem des Benutzers in-

nerhalb 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 lei-

tet die Anfragen an den Hostkernel als gew¨ohnlicher Usermode-Prozess wei-

ter.

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-

Benutzerprozesse debugged 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 mo-

difizieren, 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, so-

weit 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 Benut-

zer definierten Bereich in der Verzeichnishierachie und im Hauptspeicher,

der f¨ur die eingeschlossenen Programme als gesamt verf¨ugbarer Ressourcen-

bereich 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 wer-

den, die durch ein simuliertes Netzwerk miteinander verbunden werden. Dies

l¨asst sich durch unterschiedliche Varianten realisieren. Ein daf¨ur notwendi-

ger Switch wird als eigenst¨andiges Hostprogramm von UML zur Verf¨ugung

gestellt. Instanzen k¨onnen mit

tun"- oder

tap"-Schnittstellen

verbunden

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

oder Systemen außerhalb des Hostsystems aufnehmen. Eine weitere M¨oglich-

keit beschr¨ankt sich lediglich auf UML-Instanzen, wobei keine Schnittstellen

vom Host zur Verf¨ugung gestellt werden und eventuelle Gef¨ahrdungen in-

nerhalb 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 Funktio-

nalit¨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 Benutzer-

programme, als auch Betriebssysteme zugeordnet werden kann. UML ist der

Kategorie der Systemvirtualisierung zuzuordnen, dessen Funktionalit¨at sich

von weiteren Virtualiserungstechnologien stark unterscheidet. Eine UML-

Instanz wird vom Benutzer in einem Hostsystem als Benutzerprogramm ge-

startet und ohne Root-Privilegien am Hostsystem ausgef¨uhrt. UML verzich-

tet auf eine Virtualisierungsschicht. Die Architekturschnittstelle des UML-

Kernels ist 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 Be-

triebssystems. 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 be-

trachtet 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 ei-

nem 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 Host-

system erm¨oglichen, werden aus unterschiedlichen Blickwinkeln erkl¨art, so-

wie M¨oglichkeiten, um Ausbr¨uche zu verhindern. Abschließend werden

Einsatzgebiete er¨ortert, deren Erschließung durch UML in Zukunft geplant

ist.

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.

Kapitel 1

Grundlagen

1.1

Linux-Kernel

Der Kernel ist das Zentrum eines jeden Betriebssystems. Situiert ist der Ker-

nel als Schicht zwischen Hardwareressourcen und Anwendungsprogrammen.

Die durch die Hardware des Computers zur Verf¨ugung gestellten Ressour-

cen befinden sich im alleinigen Zugriff durch den Kernel. Diese Tatsache

stellt die Grundlage f¨ur den gleichzeitigen Betrieb mehrerer Anwendungs-

programme 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

Micro-

soft 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 Archi-

tekturen vom Kernel wahrgenommen werden, von den Anwendungspro-

grammen wahrgenommen, die diese als Bibliothek beinhalten. Der Kernel

selbst ¨ubernimmt nur die Ressourcenverwaltung. Der Vorteil dieser Archi-

tektur liegt in der Erweiterung, da diese an den Anwendungsprogrammen

selbst und individuell f¨ur ihre Einsatzzwecke vorgenommen werden k¨onnen.

KAPITEL 1. GRUNDLAGEN

Nachteilig ist jedoch, dass Programme Aufgaben, wie die Verwaltung von

Plattenbl¨ocken durch eigene Dateisysteme oder z.B. Netzwerksockets, selbst-

st¨andig implementieren m¨ussen. Diese Art der Implementierung weist keine

Sicherheitsl¨ucken auf, da die Anwendungsprogramme mit ihren Betriebs-

systemfunktionen im Usermode

betrieben werden [12, S.19].

Der Exokernel existiert in drei unterschiedlichen Implementationen

die auf der Exokernelarchitektur basieren. Diese Implementationen unter-

scheiden sich anhand der eingesetzten Hardware.

Aegis" findet Einsatz

unter

DECstations und MIPS-Prozessoren,

Glaze" f¨ur experimentelle

SPARC"-basierte Multiprozessormaschinen und

Xok", die neueste Imple-

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¨atzli-

che Funktionen sind in Serverprozessen enthalten, die im Benutzermodus

ausgef¨uhrt werden. Serverprozesse unterscheiden sich nicht von gew¨ohn-

lichen 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 Feh-

lern auf den verursachenden Serverprozess. Der Kern ist das einzige Me-

dium, 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 aus-

gelegt 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 User-

mode 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

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 Mo-

dule wirken sich durch dieses Modell negativ auf den gesamten Kern aus,

da diese auf den gesamten Kerneladressraum uneingeschr¨ankte Rechte be-

sitzen. Diese Variante erm¨oglicht jedoch, dass eine Neukompilierung des

Kernels umgangen werden kann. Der wesentlichste Vorteil in dieser Kernel-

architektur liegt in der zum Vergleich anderer Technologien hohen Perfor-

mance, da s¨amtliche Funktionen im Kernelmode ausgef¨uhrt werden und de-

ren 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 Funk-

tionen, die sich somit im Kernelmode befinden, womit ein Geschwindigkeits-

vorteil gegen¨uber dem Mikrokernel erzielt werden kann, da weniger Kontext-

wechsel 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 Ker-

nels

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

Abbildung 1.1: Aufbau des Linux-Kernels [27].

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 Been-

digung von Prozessen, der Kommunikation zwischen Prozessen untereinander,

durch Signale und Pipes sowie dem Scheduling

von Prozessen. Der Auf-

bau 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 Job-

erstellung oder durch den Elternprozess an den Kernel ¨ubergeben wer-

den, 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

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 akti-

ven Prozessen. Der Prozesswechsel kann zu einem beliebigen Zeitpunkt erfol-

gen, 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 Termi-

nierung eines Prozesses kann auch durch seinen Vaterprozess veranlasst wer-

den oder durch das Betriebssystem selbst.

Ein weiteres Aufgabengebiet ist die Interprozesskommunikation, die der

Kommunikation von Prozessen untereinander dient, da diese in unterschied-

lichen Adressr¨aumen liegen und somit keinen direkten Zugriff zueinander

erlangen k¨onnen.

Die Prozessverwaltung ¨ubernimmt auch die Verwaltung der Prozess-

kontrollbl¨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] abgebil-

det.

Speicherverwaltung

Die Speicherverwaltung bezieht sich auf den Hauptspeicher eines Computer-

systems, 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 Adres-

sen 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 par-

allele Ausf¨uhrung mehrerer Prozesse unterst¨utzen, k¨onnen den gesamten

Prozess, aber auch Teile unterschiedlicher Prozesse im Hauptspeicher hal-

ten. 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

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¨auter-

ung findet sich im Abschnitt 1.3.1 wieder.

Dateisysteme

Uber die Hardware des Systems legt der Kernel ein strukturiertes Datei-

system. Diese Datei-Abstraktion findet sich im gesamten Betriebssystem

wieder. Linux unterst¨utzt unterschiedliche Dateisysteme. F¨ur blockorien-

tierte Ger¨

ate, wie z.B. die Festplatte, werden Systeme wie ext3, reiserfs,

oder auch fat verwendet. Informationen ¨uber Kernelkonfigurationen so-

wie die Systemzust¨ande werden durch das in Linux vorhandene proc-Datei-

system in 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 Tastatur-

eingaben, verlangen vom Betriebssystem eine Steuerung dieser Komponen-

ten. 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 Hardware-

komponenten 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¨atetrei-

ber 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 Pro-

zesse auch die Netzwerkschicht zur Kommunikation untereinander verwen-

den k¨onnen.

Ein erster Unterschied zu Block- und Zeichenger¨aten liegt darin, dass

Netzwerkschnittstellen nicht in Form einer Datei im Betriebssystem repr¨asen-

tiert 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

sondern dieser bei einkommenden Netzwerkpaketen dies dem Kernel durch

Interrupts signalisieren muss. Diese Pakete der Netzwerkschicht des Ker-

nels sind unabh¨angig von den eingesetzten Netzwerkprotokollen

der User-

programme sowie der darunter liegenden Hardwareprotokolle

Programme, welche Netzwerkaktivit¨aten verfolgen, m¨ussen, um Netz-

werkpakete senden und empfangen zu k¨onnen, eine Verbindung zum Netz-

werkkartentreiber aufbauen. Diese Verbindung wird auch als Socket be-

zeichnet. Eine Netzwerkschnittstelle kann eine Vielzahl von Sockets gleich-

zeitig 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

sys-

sockcall"-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 zugrunde-

liegenden ¨

Ubertragungsprotokoll der Pakete wird die passende Socketimple-

mentierung ausgef¨uhrt.

Das

Netdevice Interface" als nachfolgende Schicht organisiert die zu sen-

denden Pakete durch Pufferung in einer Warteschlange, welche anschließend

an den Treiber weitertransportiert werden. Diese Schicht bietet die M¨oglich-

keit, Datenpakete nach bestimmten Kriterien, wie verwendetes Protokoll

oder Sender- und Empf¨anger, zu filtern und diese in unterschiedliche Warte-

schlangen aufzuteilen. Diese Warteschlangen werden unterschiedlich oft ab-

gerufen, 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 Netzwerkschnittstellen-

karten. 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 versen-

det. 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 ver-

teilt. 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).

KAPITEL 1. GRUNDLAGEN

Art des Schedulings

Beschreibung

langfristiges Scheduling

Die Entscheidung, ob und wann ein neuer Pro-

zess erzeugt wird. Diese Entscheidung h¨angt

von der Zahl der aktuell betriebenen Prozesse

ab.

Je h¨oher diese Zahl ist, desto weniger

Rechenzeit bleibt f¨ur einen einzelnen Prozess

uber.

mittelfristiges Scheduling

Die Entscheidung, einen ausgelagerten Pro-

zess in den Hauptspeicher zu laden. Dieser

Faktor ist abh¨angig von der Auslastung des

Hauptspeichers und des Bedarfs der aktuell im

Hauptspeicher eingelagerten Prozesse.

kurzfristiges Scheduling

Die Entscheidung, welcher Prozess als N¨achstes

bearbeitet wird.

Tabelle 1.1: Arten des Schedulings [31, S.458].

Das kurzfristige Scheduling

wird w¨ahrend der Ausf¨uhrung des Betriebs-

systems am h¨aufigsten durchgef¨uhrt. Die Entscheidung, welcher Prozess als

N¨achstes Rechenzeit zugeteilt bekommt, ist ein wichtiges Kriterium f¨ur die

Performance eines Systems.

Unterschiedliche Betriebssysteme besitzen Scheduler, welche die Aus-

wahl der Prozesse nach unterschiedlichen Kriterien handhaben. Scheduler

in Betriebssystemen, die f¨ur den Privatanwender gedacht sind, werden dazu

optimiert, dass die Auswahl und die Dauer der Ausf¨uhrung auf interaktive

Prozesse fokussiert wird, w¨ahrend bei Serverbetriebssystemen eine effektive

Nutzung der Rechenzeit im Vordergrund steht. Ein Prozess wird mit einer

Priorit¨at versehen. Prozesse mit h¨oherer Priorit¨at

werden vom Schedu-

ler mit einer gr¨oßeren Wahrscheinlichkeit ausgew¨ahlt als jene mit niedriger

Priorit¨at. Ein Scheduler kann nicht erst alle Prozesse mit der h¨ochsten

Priorit¨at abarbeiten, da solange sich Prozesse mit dieser Priorit¨at in der

Warteschlange befinden, keine Prozesse mit niedriger Priorit¨at ausgef¨uhrt

werden k¨onnen und somit verhungern.

Scheduler benutzen unterschiedliche Algorithmen, welche die Auswahl

des n¨achsten Prozesses bestimmen [31, S.467].

· FCFS (First Come First Served): Jener Prozess, der als Erstes in die

Warteschlange kommt, wird ausgef¨uhrt. Der Scheduler ist einfach zu

realisieren und ressourcenschonend, Prozesse werden jedoch nicht nach

ihrer Dringlichkeit behandelt.

Dieser Scheduler wird auch als

Dispatcher bezeichnet [31, S.461].

z.B. Musikplayer.

KAPITEL 1. GRUNDLAGEN

· Round Robin: Aus allen auszuf¨uhrenden Prozessen wird per Zufall ein

Prozess ausgw¨ahlt. Das Problem ist, wie bei FCFS, dass theoretisch

Prozesse nie zur Ausf¨uhrung ausgew¨ahlt werden.

· SPN (Shortest Process Next): Prozesse, deren Ausf¨uhrung weniger

Rechenzeit ben¨otigt, werden bevorzugt. Existieren viele solche Pro-

zesse, wird die Ausf¨uhrung von Prozessen mit l¨angerer Rechenzeit

stark benachteiligt.

· SRT (Shortest Remaining Time): Jener Prozess, der noch die k¨urzeste

verbleibende Verarbeitungszeit aufweist, wird ausgew¨ahlt. Kurze, aber

wichtige Prozesse werden nicht bevorzugt, was aus Sicht des Benutzers

einen extremen Performanceeinbruch bedeuten kann.

· HRRN (Highest Response Ratio Next): Jener Prozess wird ausgew¨ahlt,

welcher am l¨angsten zur Abarbeitung bereitsteht. Nachteile wie bei

SRT.

1.2

Prozessmanagement

1.2.1

Prozesse vs. Threads

Bei Prozessen und Threads handelt es sich um keine Konkurrenzprodukte,

welche das gleiche Ziel verfolgen. Ein Thread ist lediglich Bestandteil eines

Prozesses, welcher die Ausf¨uhrung des Programmcodes vornimmt, w¨ahrend

der Prozess selbst die zur Ausf¨uhrung notwendigen Ressourcen bereitstellt.

Prozesse

Ein Programm, welches sich in Ausf¨uhrung befindet, wird als Prozess titu-

liert. Jeder Prozess bekommt einen eigenen Adressraum zugewiesen, welcher

bei

x86"-Architekturen 4 GB betr¨agt. Davon erh¨alt der Kernel 1 GB. Die

Ausf¨uhrung eines Programmes fordert zahlreiche Ressourcen, wie unter Ab-

bildung 1.2 dargestellt, die im Adressraum bereitgestellt sein m¨ussen.

Jeder Prozess besitzt einen Prozessdeskriptor, in dem Informationen f¨ur

den Kernel zur Verwaltung des Prozesses abgelegt sind. Eine Erl¨auterung

des Prozessdeskriptors findet sich im Abschnitt 1.2.2 wieder.

Zur Ausf¨uhrung des Programmes muss auch dessen Programmcode zur

Verf¨ugung stehen. Dieser kann in einer beliebigen (Hoch)sprache geschrie-

ben werden und muss anschließend zu Maschinencode kompiliert werden.

Variablen und Konstanten erhalten ebenfalls einen separaten fixen Speicher-

bereich, da die Anzahl und Gr¨oße dieser Objekte schon zum Programmstart-

punkt bekannt sind und sich w¨ahrend der Laufzeit nicht ver¨andern.

Der n¨achste Abschnitt ist der Heap. Dessen Gr¨oße ist nicht statisch,

sondern ver¨andert sich zur Laufzeit. Am Heap k¨onnen Speicherbereiche

KAPITEL 1. GRUNDLAGEN

Abbildung 1.2: Elemente eines Prozesses im virtuellen Adressraum bei 32-

Bit-Architektur.

allokiert werden

. Dies wird vor allem dann ben¨otigt, wenn der Prozess

externe Dateien l¨adt oder dynamische Objekte

anlegt, deren Anzahl und

Gr¨oße w¨ahrend der Laufzeit durch externe Faktoren beeinflusst werden kann.

Der letzte Bereich ist der Stack, der ebenfalls ¨uber eine variable Gr¨oße

verf¨ugt. Im Gegensatz zum Heap liegt der Beginn des Stacks am Ende des

Adressraums und w¨achst in des Heaps entgegengesetzte Richtung. Am Stack

werden dynamische Speicherstrukturen, wie etwa ¨

Ubergabeparameter und

Return-Werte von Funktionen abgelegt.

Threads

Der Thread ist die Einheit eines Prozesses, die f¨ur die Ausf¨uhrung auf der

CPU verwaltet werden [32, S.97]. Aufgaben werden nicht durch den Pro-

zess abgearbeitet, sondern durch seine Threads. Jeder Prozess besitzt nach

seiner Generierung mindestens einen Thread, kann aber durchaus mehrere

besitzen. Ein Thread befindet sich im Adressraum seines Prozesses und ver-

wendet die davon zur Verf¨ugung gestellten Ressourcen. Jeder Thread be-

sitzt zus¨atzlich einen

ProgrammCounter"

, Register f¨ur lokale Variabeln

C stellt dazu die Funktion

malloc()" bereit.

Unter Java werden solche Objekte mit dem

New"-Operator angelegt.

Gibt an, welcher Schritt als N¨achstes ausgef¨uhrt wird.

Details

Seiten
Erscheinungsform: Originalausgabe
Jahr: 2007
ISBN (eBook): 9783836629874
DOI: 10.3239/9783836629874
Dateigröße: 1 MB
Sprache: Deutsch
Institution / Hochschule: Fachhochschule Oberösterreich Standort Hagenberg – Software Engineering
Erscheinungsdatum: 2009 (Mai)
Note: 1,0
Schlagworte: betriebssystem linux virtualisierung sicherheit netzwerk

Autor

Christoph Scharnböck (Autor:in)