Optimierung der Schnittstelle zwischen Hypervisor und Betriebssystemkern bei virtuellen Maschinen

Transkript

1 Optimierung der Schnittstelle zwischen Hypervisor und Betriebssystemkern bei virtuellen Maschinen Der Technischen Fakultät der Universität Erlangen-Nürnberg zur Erlangung des Grades DOKTOR-INGENIEUR vorgelegt von Hans-Jörg Höxer Erlangen 2008

2 Als Dissertation genehmigt von der Technischen Fakultät der Universität Erlangen-Nürnberg Tag der Einreichung: Tag der Promotion: Dekan: Prof. Dr. Johannes Huber Berichterstatter: Prof. i.r. Dr. rer. nat. Dr. h.c. Mario Dal Cin Prof. Dr.-Ing. Wolfgang Schröder-Preikschat

3 Danksagung An dieser Stelle möchte ich mich bei Herrn Prof. Dal Cin für die Betreuung und Begutachtung meiner Arbeit sowie bei Herrn Prof. Schröder-Preikschat für die Übernahme des Zweitgutachten bedanken. Mein Dank gilt auch Herrn Prof. Helmreich und Herrn Prof. German für ihre freundliche Unterstützung. Meinem Kollegen Volkmar Sieh danke ich für Betreuung, konstruktive Kritik und Teamgeist während der Entstehung dieser Arbeit. Bei allen Kolleginnen und Kollegen des Lehrstuhls bedanke ich mich für die Unterstützung, die ich in meiner Zeit an der Universität Erlangen erfahren durfte. Ganz besonders herzlich danke ich meinen Eltern und Geschwistern für ihre Unterstützung und Rückhalt, ohne den diese Arbeit nicht hätte entstehen können. Besonderer Dank geht an Martin Kastner für stets konstruktive und wertvolle Kritik sowie moralische Unterstützung während aller Entstehungsphasen dieser Arbeit. Ebenso danke ich Thomas Zinnbauer für seine Unterstützung.

4

5 Kurzfassung In dieser Arbeit wird ein Verfahren entwickelt, das zur Optimierung der Schnittstelle zwischen dem Hypervisor einer virtuellen Maschine und dem darauf ausgeführten Gastbetriebssystem dient. Das Ziel der Optimierung ist, teure Aufrufe des Hypervisors durch das Betriebssystem zu reduzieren, indem Aufrufe zusammengefasst oder ganz vermieden werden. Die grundlegende Idee des entwickelten Verfahrens ist, Sequenzen privilegierter Instruktionen im Kontrollfluss des Gastbetriebssystems zu erkennen, da diese Instruktionen Aufrufe des Hypervisors zur Folge haben und somit den Virtualisierungsaufwand beeinflussen. Die Untersuchung erkannter Sequenzen läßt Rückschlüsse auf mögliche Modifikationen am Gastbetriebssystem und dem Hypervisor zur Umsetzung der genannten Ziele zu. Zur Erkennung von Sequenzen wird die virtuelle Maschine FAUmachine so modifiziert, dass privilegierte Instruktionen im Kontrollfluss eines Gastbetriebssystems, das auf FAUmachine ausgeführt wird, protokolliert werden. Ein so gewonnenes Protokoll wird nach Sequenzen durchsucht, indem der nichtdeterministische erkennende Automat zu dem Protokoll konstruiert wird, an dem sich dann existierende Sequezen ablesen lassen. Zur Bewertung gefundener Sequenzen bezüglich ihrer Länge und Häufigkeit wird deren Signifkanz berechnet, welche es ermöglicht, die Sequenzen zu identifizieren, die einen hohen Anteil am Virtualisierungsaufwand haben. Diese Schritte werden mit einer Reihe von Werkzeugen implementiert, die eine automatische Untersuchung eines Gastbetriebssystems ermöglichen. Das Betriebssystem OpenBSD wird mit dem entwickelten Verfahren analysiert und basierend auf den gefundenen Sequenzen prototypisch durch Modifikationen optimiert. Die Wirksamkeit der vorgenommenen Optimierungen wird durch erneutes Analysieren des optimierten Systems mit dem entwickelten Verfahren geprüft und nachgewiesen.

6 Summary In this thesis a method is developed, that optimizes the interface between the hypervisor of a virtual machine and the guest operating system run on the virtual machine. It is the goal of the optimization to reduce expensive hypervisor calls of the guest operating system by either combining or avoiding calls. The fundamental idea of the developed method is to find sequences of privileged instructions in the control flow of the guest operating system. As these instructions result in hypervisor calls they have impact on the overhead introduced by virtualization. Examination of the found sequences allows to deduce possible modification for both the guest operating system and the hypervisor to meet the goals. The virtual machine FAUmachine is modified to log sequences of privileged instructions in a guest operating system while running it on the virtual machine. The generated log files are examined for sequences by constructing the nondeterministic recognizing automaton of the log and deriving sequences from the states of the automaton. To evaluate derived sequences regarding length and frequency their so called significance is calculated which allows to identify those sequences that contribute clearly to the virtualization overhead. A number of tools is developed to perform all these steps in an automated fashion. Using this method the operating system OpenBSD is analyzed and based on the found sequences some modifications are implemented that reduce the virtualization overhead. The virtue of these optimizations is proofen by re-evaluating the modified system with the described method.

7 Inhaltsverzeichnis Abbildungen v 1 Einleitung Motivation Einordnung und Beitrag dieser Arbeit Inhaltsübersicht Konventionen und Bezeichnungen Problemstellung Virtualisierungstechniken Hypervisor Abstraktionsniveaus Kosten von Hypervisor Aufrufen Eine Methode zur Optimierung IA 32 Laufzeitumgebung Überblick Ressourcen der IA Adressraum Register x87 FPU und MMX/XMM Register Stack Spezialregister Prozessorstatuswort Register für Deskriptortabellen Segmentregister Kontrollregister Prozessor Modi Schutzmodell des Protected Mode Long Mode Kontexte Prozess- und Hardwarekontext Ausführungskontext und Prozessormodus i

8 ii INHALTSVERZEICHNIS 3.6 Zusammenfassung Virtualisierung Virtuelle Maschinen, Hypervisor und VMM Laufzeitumgebung und Äquivalenz Effizienz Kontrolle von Ressourcen Maschinenmodell Prozessor, Speicher und Zustand Traps und Exceptions Klassifizierung von Instruktionen Virtualisierbarkeit Virtual Machine Map Aufbau eines VMM Aufbau Typen von VM Monitoren Virtualisierung von Hardwarekomponenten Prozess- und Ressourcen Tabelle Komponentenemulation Aufbau virtueller Maschinen Zusammenfassung Virtualisierung von IA Sensible nicht privilegierte Instruktionen lidt und sidt pushf und popf Probleme der Architektur Segmentierung Kontrollfluss Virtualisierungstechniken für IA Virtualisierungstechniken bei FAUmachine Überblick ISA Virtualisierung Zusammenfassung Methode Virtualisierungs Target Sequenzen Definition Beispiel für Sequenzen Methoden Statische Code Analyse Dynamische Programm Analyse

9 INHALTSVERZEICHNIS iii 6.4 Dynamische Programm Analyse mit FAUmachine Instrumentierung von Translated Blocks Instrumentierung von Interrupts und Exceptions Protokolle Einschränkungen Overhead der Instrumentierung Zusammenfassung Experimente Funktionen eines UNIX Kerns Workload und Experiment Einfache Experimente Komplexe Experimente Experimente mit FAUmachine Zusammenfassung Auswertung Vorgehensweise Präprozessor Real Mode Kontext Prozesskontext Interruptkontext Implementierungsdetails Erkennung von Sequenzen Signifikanz von Sequenzen Profile Auswertungssystem Verifikation Zusammenfassung Diskussion Ergebnisse der Auswertung Sequenzen bei OpenBSD Profile für OpenBSD Zusammenfassung der übrigen Experimente Optimierungen für OpenBSD Optimierung für Segmentregister Optimierung für CR Verifikation Probleme und Einschränkungen Zeit zwischen Instruktionen Betonung von Interrupts Zusammenfassung

10 iv INHALTSVERZEICHNIS 10 Zusammenfassung 105 Literaturverzeichnis 107 A Beispiel zur Verfikation 113 B Sequenzendatenbänke 115 B.1 nopc.db B.2 pc.db B.3 int.db C Funktionsprofil 123

11 Abbildungsverzeichnis 3.1 Ausführungskontexte und Prozessormodus Virtual Machine Map Sensible nicht-privilegierte Instruktionen nach [RI00] Speichern von Segmentselektoren Laden von Segmentselektoren Kontrollfluss und Segmentierung Die Funktion pmap update 2pg() Die Funktionen tlbflush() und invlpg() Disassemblierter Ausschnitt aus pmap copy page() Auszug aus disas insn() gen trace * Prototypen Beispiel für ein Protokoll Objektcode zum Protokoll in Abbildung Overhead der Instrumentierung bei der Installation von OpenBSD Workload 1 (OpenBSD wird gestartet und heruntergefahren) Workload 2 (Installieren von OpenBSD 3.7) Makefile für Experiment mit Workload 2 (Auszug) Durchgeführte Experimente Protokolle aller Experimente und deren Größe Tools zur Auswertung von Protokollen Einschalten von Paging und Protected Mode Das Protokoll zum in 8.2 gezeigten Code Protokoll Datenstruktur Vom Präprozessor zerlegtes Protokoll Auszug aus einem Protokoll Automat zu Abbildung 8.6 ohne Berücksichtigung des PC und mit Auszug aus einer Sequenzdatenbank v

12 vi ABBILDUNGSVERZEICHNIS 8.10 Auszug aus einem mit fprofile erzeugtem Funktionsprofil Auszug aus einem mit iprofile erzeugtem Instruktionsprofil Ergebnisse der Auswertung eines Teilprotokolls Beispiel einer nur durch manuelle Inspektion gefundene Sequenz Auszug aus nopc.db zu Experiment Auszug aus nopc-int.db zu Experiment Auszug aus nopc.db zu Experiment Auszug aus pc.db zu Experiment Auszug aus int.db zu Experiment Auszug aus pc.db zu Experiment Auszug aus int.db zu Experiment Instruktionsprofil für Experiment Instruktionsprofil für Experiment Funktionsprofil für Experiment 1 (Auszug) Funktionsprofil für Experiment 2 (Auszug) Funktionsprofil des 4.0 Kerns (Auszug) Funktionsprofil des optimierten 4.0 Kerns (Auszug) Die Funktion pmap copy page() Auszug aus einem mit gprof(1) erzeugten Profil Skript zur Lasterzeugung für Profiling Auszug aus dem Profil der uninstrumentierten FAUmachine Auszug aus dem Profil der instrumentierten FAUmachine Verhältnis von Interrupt-, Exception- und Systemcall Behandlung. 102

13 Kapitel 1 Einleitung 1.1 Motivation Der Begriff virtuelle Maschine (VM) bezeichnet eine Software-Implementierung einer realen Maschine [PG74]. Diese Software bildet die Laufzeitumgebung, wie sie von der realen Maschine bereitgestellt wird, vollständig nach, so dass ein Betriebssystem für die reale Maschine auch auf der virtuellen Maschine ausgeführt werden kann. Es sei erwähnt, dass inzwischen der Begriff virtuelle Maschine erweitert wurde und sich nun auch auf Maschinen bezieht, denen keine reale Hardware zugrunde liegt. Ein Beispiel ist die Java Virtual Machine (JVM), die alle nötigen Funktionen implementiert, um Programme der Programmiersprache Java ausführen zu können. Diese Arbeit befasst sich mit der zuerst genannten Klasse virtueller Maschinen, die reale Hardware auf Software abbilden. Die Abbildung einer realen Hardware auf ein virtuelle Maschine wird realisiert, indem eine Abstraktionsschicht zwischen Hardware und Gastbetriebssystem 1 eingeführt wird. Diese Abstraktionsschicht wird als Hypervisor oder auch virtueller Maschinen Monitor (VMM) bezeichnet. Dessen Aufgabe ist es, privilegierte Operationen des Gastbetriebssystems abzufangen und diese entweder zu emulieren oder stellvertretend für das Betriebssystem durchzuführen. Privilegierte Operationen sind beispielsweise direkte Zugriffe auf die Hardware oder spezielle Register des Prozessors. Diese Zugriffe müssen auf die Schnittstelle zwischen Hypervisor und Betriebssystem abgebildet werden. Verglichen mit einem realen Hardwarezugriff durch das Betriebssystem ist ein virtualisierter Zugriff um Größenordnungen teurer. In erster Näherung ist ein Hypervisoraufruf mindestens genauso teuer wie ein Systemaufruf bei gängigen UNIX Systemen, da in beiden Fällen der komplette Zustand des Prozessors gesi- 1 Ein Betriebssystem, das auf einer virtuellen Maschine ausgeführt wird, bezeichnet man als Gastbetriebssystem oder kurz Gast. 1

14 2 KAPITEL 1. EINLEITUNG chert wird, der Adressraum umgeschaltet werden muss, etc. Die Performance einer virtuellen Maschine ist also an die Häufigkeit und die Kosten von Hypervisor Aufrufen gekoppelt. Zur Verbesserung der Performance einer virtuellen Maschine hinsichtlich Hypervisor Aufrufen ist es denkbar, den Hypervisor Aufruf also das Umschalten zwischen Kern und Hypervisor zu beschleunigen. Hierzu könnte beispielsweise untersucht werden, ob sich Techniken zur Beschleunigung von Systemaufrufen, wie sie von Liedtke in [Lie95a, Lie95b] für Micro Kernel Architekturen vorgeschlagen wurden, auf einen Hypervisor anwenden lassen. Ein Nachteil dieser Techniken ist aber, dass sie stark auf den jeweils verwendeten Prozessor zugeschnitten sind. Daher wird in dieser Arbeit versucht, den Weg für eine generische Lösung für dieses Problems zu bereiten. 1.2 Einordnung und Beitrag dieser Arbeit Es wird eine Methode zur Identifizierung von Sequenzen privilegierter Operationen im Kontrollfluss eines Betriebssystems mittels Experimenten entwickelt. Das Vorkommen der so identifizierten Sequenzen kann nun gemessen und statistisch ausgewertet werden. Basierend auf diesen Werten kann die Schnittstelle zwischen Hypervisor und Betriebssystem, die die Funktionalität privilegierter Operationen bieten muss, so angepasst werden, dass die Zahl der Hypervisor Aufrufe reduziert werden kann bzw. dass mehrere privilegierte Operationen auf einen einzigen Aufruf abgebildet werden können. Dies kann sowohl auf der Ebene des Betriebssystems als auch des Hypervisors selbst geschehen. Die Arbeit leistet die folgenden Beiträge: Einführung und Implementierung der zentralen Idee: Identifizierung von Sequenzen privilegierten Operationen im Kontrollfluss eines Betriebssytems liefert Informationen über die Schnittstelle zwischen Kern und Hypervisor (Kapitel 6). Definition und Durchführung von Experimenten, die zur Lasterzeugung auf dem zu untersuchenden Betriebssystem ausgeführt werden (Kapitel 7). Auswertung identifizierter privilegierter Operationen und Erkennung von Sequenzen am Beispiel von OpenBSD (Kapitel 8). Exemplarische Optimierung des OpenBSD Kerns basierend auf Sequenzen identifizierter privilegierter Operationen (Kapitel 9).

15 1.3. INHALTSÜBERSICHT Inhaltsübersicht Diese Arbeit gliedert sich wie folgt: In Kapitel 2 wird die Problemstellung dieser Arbeit erläutert. Dazu wird beschrieben, wie bei gängigen Virtualisierungstechniken das Betriebssystem mit dem Hypervisor der virtuellen Maschine interagiert und wie daraus die Schnittstelle zwischen Kern und Hypervisor zustande kommt. Davon wird die zentrale Idee dieser Arbeit abgeleitet. In Kapitel 3 wird die Laufzeitumgebung der IA 32 ( Intel Architecture 32 ) Prozessoren vorgestellt. Es werden die wesentlichen Elemente der Architektur besprochen, die für das Verständnis dieser Arbeit nötig sind. Kapitel 4 beschreibt die theoretischen Grundlagen der Virtualisierung nach Popek und Goldberg. Die von ihnen geschaffene Klassifizierung von Instruktionen und deren Beziehung zur Virtualisierbarkeit einer Instruktionssatzarchitektur ist wesentlich für die Identifizierung von privilegierten Operationen. Inwiefern sich die von Popek und Goldberg aufgestellten Prinzipien auf IA 32 übertragen lassen, wird in Kapitel 5 untersucht. Diese Überlegungen schaffen die Grundlage zur Identifizierung von privilegierten Operationen. In Kapitel 6 werden Methoden zur Erfassung privilegierter Operationen untersucht. Dazu wird zunächst definiert, was genau unter einer Sequenz privilegierter Operationen zu verstehen ist. Dann werden verschiedene Methoden vorgestellt und bewertet. Abschließend wird die Implementierung einer ausgewählte Methode besprochen. In Kapitel 7 werden Experimente definiert, die zur Lasterzeugung auf dem zu untersuchenden Betriebssystem ausgeführt werden. Ziel der Experimente ist es, eine realistische Abdeckung der Pfade im Kontrollfluss zu erreichen, die privilegierte Operationen enthalten. Das Kapitel 8 beschreibt die Auswertung der durchgeführten Experimente. Dazu werden Techniken zur Erkennung von Sequenzen privilegierter Operationen beschrieben und eine Methode zur Bewertung von Sequenzen vorgestellt. In Kapitel 9 werden dann am Beispiel von OpenBSD identifizierte Sequenzen besprochen. Ausgehend von diesen Sequenzen werden Möglichkeiten zur Optimierung der Schnittstelle zwischen OpenBSD Kern und Hypervisor vorgestellt, implementiert und durch Wiederholung von Experimenten validiert. Im Anhang dieser Arbeit wird eine Auswahl der in den Experimenten gewonnen Daten präsentiert.

16 4 KAPITEL 1. EINLEITUNG 1.4 Konventionen und Bezeichnungen Verwendete Programmtexte sind zu Gunsten der Lesbarkeit in gekürzter und vereinfachter Form angegeben, wobei es im Wesentlichen auf die Struktur und die jeweils grundlegenden Algorithmen ankommt. Der genaue Programmtext kann in den jeweils angegebenen Quellen nachgelesen werden. Dateinamen, Systemaufrufe, Funktionsnamen und Mnemonics sind im Schreibmaschinenstil angegeben. Bei Systemaufrufen und UNIX-Kommandos wird zusätzlich in Klammern die Kapitelnummer der jeweiligen Manual-Seite angegeben, welche mit dem UNIX-Kommando man(1) nachgelesen werden kann. Die Bedeutung von Systemaufrufen, UNIX-Kommandos und IA 32 Instruktionen wird in der Regel als bekannt vorausgesetzt. Bei Funktionen wird bei erstmaliger Nennung der Name und Pfad der Quelldatei als Fußnote angegeben. Die Bedeutung von Mnemonics kann in [Int06b, Int06c] nachgeschlagen werden.

17 Kapitel 2 Problemstellung Dieses Kapitel erläutert die Problemstellung dieser Arbeit. Dazu werden zuerst zwei prinzipiell unterschiedliche Virtualisierungstechniken vorgestellt und die zu deren Umsetzung nötigen Hypervisoren beschrieben. Anschließend werden Abstraktionsstufen identifiziert, auf den Virtualisierung in Betriebssystemen ansetzen kann und die Kosten von Hypervisor Aufrufen erläutert. Darauf aufbauend werden die Grundzüge der in dieser Arbeit entwickelten Methode zur Optimierung der Schnittstelle zwischen Hypervisor und Betriebssystemkern erklärt. 2.1 Virtualisierungstechniken Es existieren zwei gängige Arten von Virtualisierung, vollständige Virtualisierung und Paravirtualisierung. Bei vollständiger Virtualisierung ist die virtuelle Maschine ein Duplikat der realen Maschine. Dieses Duplikat hat die gleichen 1 Eigenschaften wie die reale Maschine. Daher können Betriebssysteme und Anwendungen für die reale Maschine unverändert auf dem Duplikat ausgeführt werden. Für das Betriebssytem ist kein Unterschied zwischen realer und virtueller Maschine erkennbar. Wie in Kapitel 5 näher beschrieben wird, ist dies auf IA 32 nur bedingt zu realisieren. Die theoretischen Grundlagen für vollständige Virtualisierung werden in Kapitel 4 erläutert. Bei Paravirtualisierung ist die virtuelle Maschine kein Duplikat einer realen Maschine, sondern eine rein virtuelles Konstrukt. Dieses ist aber in der Regeln an die Eigenschaften und die Funktionsweise einer realen Maschine angelehnt, aber nicht äquivalent. Ein großer Vorteil dieser Technik ist, dass sie weniger komplex ist als vollständige Virtualisierung. Ein deutlicher Nachteil ist aber, dass ein Betriebssystem für eine reale Maschine nicht auf der virtuellen Maschine ausgeführt werden kann, ohne vorher an diese angepasst zu werden. 1 Eine Ausnahme stellt das Zeitverhalten der virtuellen Maschine dar, siehe Kapitel

18 6 KAPITEL 2. PROBLEMSTELLUNG 2.2 Hypervisor Das Herzstück einer virtuellen Maschine bildet der sogenannte Hypervisor oder Virtual Machine Monitor (VMM). Dieser agiert stellvertretend für das Gastbetriebssystem mit der realen Hardware. Durch diese Entkopplung wird es möglich, mehrere Betriebssystem nebenläufig auf der gleichen realen Maschine in virtuellen Maschinen zu betreiben. Ein populärer Hypervisor für Paravirtualisierung ist Xen [Xen]. Um ein Betriebssystem wie GNU/Linux [Lin] oder NetBSD [Net] auf Xen zu betreiben, muss der Betriebssystemkern auf die Schnittstelle des Xen Hypervisors portiert werden, da der Kern privilegierte Operationen nicht mehr selber ausführt, sondern den Hypervisor beauftragt. Daher müssen im Quellcode alle privilegierten Operationen durch Hypervisor Aufrufe ersetzt werden. Das gleiche gilt für Interruptund Exception Behandlungsfunktionen, die der Kern beim Hypervisor anmeldet. Der Hypervisor fängt alle Interrupts und Exceptions ab und leitet sie gegebenenfalls weiter an den Kern, der eine entsprechende Behandlungsroutine registriert hat. Die Systemschnittstelle des Xen Hypervisor ist stark an der Architektur des Gastgeberprozessors orientiert, um die Portierung eines Kerns auf den Hypervisor zu vereinfachen und um die Modifikationen am Kernel Quellcode gering zu halten. Dies ist vergleichbar mit dem Ansatz von User Mode Linux [Dik] (UML) und FAUmachine 2 [FAUa], bei dem der Linux Kern auf die Systemschnittstelle von GNU/Linux portiert wird, wobei privilegierte Operationen auf geeignete Systemaufrufe abgebildet werden. Die Systemschnittstelle von GNU/Linux und UNIX generell realisiert eine abstrakte Sicht auf das Programmiermodell des Prozessors. So werden etwa Interrupts und Exceptions auf Signale und virtueller Speicher auf das Einblenden von Seiten aus Dateien, die den physikalischen Speicher darstellen, in den Adressraum eines Prozesses abgebildet. Die Systemschnittstelle ist abstrakt genug, um architekturunabhängig zu sein. Das heißt, ein Programm kann ohne Modifikationen nach erneuter Übersetzung auf einer anderen Prozessor-Architektur ausgeführt werden, da prozessorspezifische Details durch Abstraktion verborgen werden. Verglichen mit dem Interface des Xen Hypervisors besitzt die UNIX Systemschnittstelle also eine wesentlich höhere Abstraktion. Wie FAUmachine und UML aber zeigen, ist es auch auf diesem Abstraktionsniveau möglich, den Linux Kern zu implementieren. Im Folgenden werden UML, FAUmachine und vergleichbare Systeme, wie zum Beispiel die User Mode Implementierung des L4 Kernel [L4] Fiasco [Fia], unter dem Begriff User Mode Kernel zusammengefasst. 2 FAUmachine wurde ursprünglich UMLinux genannt.

19 2.3. ABSTRAKTIONSNIVEAUS 7 Im Gegensatz zur Paravirtualisierung oder einem User Mode Kernel muss bei vollständiger Virtualisierung der Hypervisor ohne Unterstützung des Betriebssystems erkennen, ob einzelne Instruktionen direkt von dem Prozessor ausgeführt werden dürfen oder vom Hypervisor virtualisiert werden müssen. Dies kann dadurch erreicht werden, dass der Prozessor bei privilegierten Instruktionen und Hardwarezugriffen eine Exception erzeugt, die vom Hypervisor abgefangen wird und die Operation emuliert wird. Dazu muss der Hypervisor in einem höher privilegierten Prozessormodus ausgeführt werden als das Betriebssystem. Die Funktionsweise vollständiger Virtualisierung ist vergleichbar mit der eines Debuggers (zum Beispiel gdb(1)), der erlaubt, Breakpoints zu setzen, Instruktionen einzeln auszuführen oder zu überspringen. Die für vollständige Virtualisierung nötigen Voraussetzungen und Techniken werden in Kapitel 4 genauer erläutert. Idealerweise ist vollständige Virtualisierung für das Betriebssystem vollkommen transparent. Ein bekannter Vertreter vollständiger Virtualisierung ist VMwareç[VMw]. 2.3 Abstraktionsniveaus Bei Paravirtualisierung, User Mode Kernel und vollständiger Virtualisierung sind unterschiedliche Ebenen von Abstraktion erkennbar. Um diese herausarbeiten zu können, folgt zunächst ein Beispiel, das anhand des Translation Lookaside Buffers (TLB) des Prozessors zeigt, wie privilegierte Operationen bei allen drei Konzepten realisiert werden. Eine zentrale Komponente der virtuellen Speicherverwaltung von IA 32-Prozessoren ist die Seiten Kachel Tabelle, die virtuelle auf physikalische Adressen abbildet. Die Tabelle steht im Hauptspeicher und der Prozessor besitzt ein Spezialregister, das die physikalischen Adresse der aktuellen Tabelle enthält. Da Hauptspeicherzugriffe teuer sind, speichert der Prozessor Adressabbildungen im TLB, nachdem er sie aus der Seiten Kachel Tabelle gelesen hat. Wird eine neue Seiten Kachel Tabelle geladen, leert der Prozessor den TLB, da die gespeicherten Abbildungen nicht mehr gültig sein müssen. IA 32 besitzt keine Instruktion zum expliziten Löschen des TLB. Typischerweise weist ein Betriebssystem jedem Adressraum eine eigene Seiten Kachel Tabelle zu und durch Laden einer neuen Tabellenadresse wechselt es von einem Adressraum zu einem anderen. Dies geschieht beispielsweise bei einem Prozesswechsel. Im Linux Quellcode existiert das C Makro tlb flush() zum Löschen des TLB. Es wird unter anderem aufgerufen, wenn ein schon existierender Eintrag in der Seiten Kachel Tabelle geändert wurde. Hat der Prozessor diesen Eintrag zuvor benutzt, befindet sich nun im TLB eine ungültige Adressabbildung und der TLB muss gelöscht werden. Dieses Makro wird in eine Folge von zwei Assemblerbefehlen übersetzt, die das Spezialregister mit der Adresse der Seiten Kachel

20 8 KAPITEL 2. PROBLEMSTELLUNG Tabelle lesen und den gelesenen Wert sofort wieder zurückschreiben. Dieser Vorgang lädt keinen neuen Adressraum, da ja nach wie vor die gleiche Tabelle verwendet wird, das Laden löscht aber den TLB. Es wird also ein Seiteneffekt beim Laden der Tabellenadresse ausgenutzt, um indirekt den gewünschten Effekt zu erzielen. Anders als IA 32 besitzt das Hypervisor Interface von Xen ein Kommando zum expliziten Löschen des TLB ( MMUEXT TLB FLUSH LOCAL ). Bei der Portierung von Linux auf Xen wird das C Makro tlb flush() so definiert, dass der Kern dieses Kommando an den Hypervisor sendet. Die Implementierung von tlb flush() des User Mode Linux ist vergleichbar. Diese entfernt mit dem Systemaufruf munmap(2) alle in den Adressraum eingeblendeten Dateiseiten, wodurch ebenfalls alle vorhandenen Adressabbildungen invalidiert werden. Beiden Implementierungen von tlb flush() ist gemein, dass anders als bei IA 32 der TLB explizit durch eine geeignete Funktion des Hypervisors bzw. der Systemschnittstelle gelöscht wird. Wird tlb flush() unter vollständiger Virtualisierung ausgeführt, erkennt der Hypervisor zuerst die Leseinstruktion und virtualisiert diese, in dem er die Adresse der aktuellen Seiten Kachel Tabelle ermittelt und an das Betriebssystem zurückliefert. Die darauf folgende Schreibinstruktion erkennt der Hypervisor ebenfalls, vermerkt die übergebene Adresse als neue Seiten Kachel Tabelle und löscht notwendiger Weise den TLB. Diese zwei privilegierten Instruktionen werden vom Hypervisor ganz analog zum Verhalten des realen Prozessors virtualisiert und als voneinander unabhängig behandelt. Dies ist ein deutlicher Unterschied zu den Vorgehensweisen von Xen und dem User Mode Linux, die das Löschen des TLB als eine privilegierte Operation behandeln. An diesem Beispiel werden zwei verschiedene Abstraktionsniveaus sichtbar. Das einzelner privilegierter Instruktionen und das privilegierter Operationen, die aus Folgen privilegierter Instruktionen bestehen können. Virtualisierung beim Xen Hypervisor und dem User Mode Linux setzt auf dem Niveau von Operationen an, vollständige Virtualisierung auf dem einzelner privilegierter Instruktionen. Um die aus diesem Unterschied resultierenden Konsequenzen beurteilen zu können, untersucht der folgende Abschnitt die Kosten der Virtualisierung. 2.4 Kosten von Hypervisor Aufrufen Es ist offensichtlich, dass die Leistung einer virtuellen Maschine verglichen mit der einer realen geringer ist, da für privilegierte Operationen der Hypervisor aufgerufen werden muss. Die Kosten eines Hypervisor Aufrufs sind im Wesentlichen darin begründet, dass der Hypervisor in einem höher privilegierten Prozessormodus

21 2.5. EINE METHODE ZUR OPTIMIERUNG 9 laufen muss (siehe Kapitel 4). Das bedeutet, dass der komplette Zustand des Prozessors gespeichert und der Adressraum umgeschaltet werden muss. Die Größenordnung dieses Aufwands ist daher vergleichbar mit der eines Systemaufrufs oder einer Exception Behandlung. Diese Abschätzung ist sowohl für Paravirtualisierung als auch für vollständige Virtualisierung gültig, auch wenn im einen Fall der Hypervisor direkt aufgerufen wird und im anderen indirekt über eine Exception. Für User Mode Linux und FAUmachine ist diese Abschätzung zumindest bei der Virtualisierung von privilegierten Operationen zutreffend. Der Aufwand zur Behandlung von Systemaufrufen an das virtualisierte Betriebssystem ist aber wesentlich größer. Details zum Aufwand bei FAUmachine sind in [Hö02] zu finden, zur Leistung allgemein in [Hö03]. Allgemein gilt aber: Die native Ausführung von privilegierten Operationen ist immer um Größenordnungen schneller als unter Virtualisierung. Aufgrund der Kosten eines Hypervisor-Aufrufs beeinflusst dessen Häufigkeit unmittelbar die allgemeine Leistung einer virtuellen Maschine. Betrachtet man das Beispiel aus dem vorherigen Abschnitt, wird ein Zusammenhang zwischen Abstraktionsniveau und der Häufigkeit von Hypervisor-Aufrufen sichtbar: Um den TLB zu löschen genügt bei Xen ein einziger Hypervisor-Aufruf, bei vollständiger Virtualisierung sind es zwei. Bei UML muss berücksichtigt werden, dass Virtualisierung zwar auf der Ebene der privilegierten Operation stattfindet, aber unter Umständen mehrere Aufrufe von munmap(2) notwendig sind, um alle Seiten aus dem Adressraum zu entfernen, wodurch die Kosten steigen. Daran wird sichtbar, dass die Systemschnittstelle verglichen mit dem Hypervisor-Interface von Xen für Virtualisierung nicht optimal geeignet ist. In [BDF + 03] wird die Leistung von Xen, UML und VMware gemessen und verglichen. Aus lizenzrechtlichen Gründen ist es den Autoren von [BDF + 03] zwar nicht erlaubt, konkrete Zahlen zu VMware zu veröffentlichen, nach eigenen Angaben aber ist Xen in allen untersuchten Aspekten leistungsfähiger als VMware und UML. 2.5 Eine Methode zur Optimierung In dieser Arbeit wird eine Methode vorgestellt, wie privilegierte Operationen durch Experimente identifiziert werden können und darauf aufbauend die Schnittstelle zwischen Hypervisor und Betriebssytem optimiert werden kann. Ausgangspunkt ist die Annahme, dass Folgen von privilegierten Instruktionen zu privilegierten Operationen zusammengefasst werden können. Diese Folgen privilegierter Instruktionen im Folgenden als Sequenzen bezeichnet können sich im Quellcode über mehrere Funktionen erstrecken. Deshalb soll versucht werden, zur Laufzeit eines Betriebssystems alle privilegierten Instruktionen zu erfassen, die virtualisiert werden müssen. Damit dazu nicht Quellcode notwendig ist und auch proprietäre Systeme unter realen Bedingungen untersucht werden können,

22 10 KAPITEL 2. PROBLEMSTELLUNG dient FAUmachine mit einem emulierten IA 32 Prozessor als Testplattform. Der Emulator wurde so modifiziert, dass zu virtualisierende Instruktionen protokolliert werden. Die Experimentierumgebung von FAUmachine wird genutzt, um Protokolle anhand eindeutig definierter und reproduzierbarer Experimente zum Beispiel Installation einer Linux Distribution gewinnen zu können. Die Protokolle werden dann nach Mustern, das heißt, wiederholt auftretende Folgen privilegierter Instruktionen, durchsucht. Um diese Folgen auf privilegierten Operationen abbilden zu können, muss deren Semantik erkannt und verstanden werden. Für Systeme, deren Objekt- und Quellcode verfügbar ist, können die gefunden Folgen den entsprechenden Funktionen wieder zugeordnet werden, was der semantischen Analyse zuträglich ist. Dazu werden eine Reihe von Werkzeugen entwickelt, um die Auswertung der Protokolle und Analyse der gefunden Folgen automatisieren zu können.

23 Kapitel 3 IA 32 Laufzeitumgebung Dieses Kapitel beschreibt die Laufzeitumgebung von IA 32 Prozessoren [Int06a] aus der Sicht des Assemblerprogrammierers. Es werden zentrale Elemente der Architektur, die für das Verständnis der folgenden Kapitel wichtig sind, kurz erläutert und zusammengefasst. Details finden sich zum Beispiel in [Int06a, Int06b, Int06c, Int06d, Thi88]. Des Weiteren werden Kontexte vorgestellte, in denen Code ausgeführt wird. 3.1 Überblick IA 32 ( Intel Architecture 32 ) ist die heute am weitesten verbreitete Prozessorarchitektur und ist sowohl in Desktop Rechnern als auch in Highend Servern zu finden. Sie hat ihren Ursprung in den 16 Bit Prozessoren 8086 und 8088 und wurde kontinuierlich erweitert. Mit dem Intel 286 Prozessor wurde der Protected Mode eingeführt, der eine Trennung von Benutzerprogrammen und dem Betriebssystem ermöglicht. Dies ist eine Voraussetzung, um Betriebssysteme der UNIX Familie zu implementieren [Vah96] 1. Der Nachfolger Intel386 2 war der erste 32 Bit Prozessor der IA 32 Familie und bot erstmals Unterstützung für Paging. Damit war der Intel386 der erste Intel Prozessor, auf dem vollwertige UNIX Betriebssysteme implementiert werden konnten. Ab dem Pentium Prozessor wurde vor allem die Leistung verbessert etwa durch weitere Pipelines und die Instruktionssatzarchitektur um SIMD Instruktionen erweitert. Heute sind mehrere Prozessorfamilien erhältlich, die alle die IA 32 implementieren: Pentium 4, Xeon, Pentium M, Pentium Extreme Edition. Ein ausführlicher Vergleich und historische Entwicklung der genannten Intel Prozessoren ist in [Int06a] zu finden. 1 Es existierten zwar UNIX Derivate für den 8086, etwa XENIX von Microsoft, diese benutzen aber keine getrennten Adressräume für Kernel und Benutzerprogramme und sind generell als eher primitive Implementierung einzustufen. Nichtsdestotrotz war XENIX kommerziell sehr erfolgreich. 2 [Int06a] verwendet die Schreibweisen Intel 286, Intel386ç und Intel486ç. 11

24 12 KAPITEL 3. IA 32 LAUFZEITUMGEBUNG 2005 führte Intel die Intel Extended Memory 64 Technology (EM64T) für die aktuellen Prozessoren ein, die IA 32 um eine 64 Bit ISA erweitert, die kompatibel zu AMDs AMD64 Architecture [AMD03a] ist. Die erweiterte ISA wird IA 32e bzw. Intel 64 genannt. IA 32e bietet einen neuen Betriebsmodus, den Long Mode, der sich im Wesentlichen in Anzahl und Breite der Register vom Protected Mode der IA 32 unterscheidet. IA 32e wird von allen neueren Auflagen der bereits genannten Prozessorfamilien Pentium und Xeon sowie der neuen Prozessorfamilie Core 2 unterstützt. 3.2 Ressourcen der IA 32 Wie in Kapitel 3.2 von [Int06a] beschrieben, stellt IA 32 einem Programm Ressourcen zum Ausführen von Instruktionen und zum Speichern von Daten, Code und Zustandsinformation bereit. Diese Ressourcen bilden die Laufzeitumgebung, die sowohl von Anwenderprogramme als auch dem Betriebssystem einheitlich verwendet werden. In den nächsten Abschnitten werden die einzelnen Ressourcen kurz erläutert Adressraum IA 32 Prozessoren haben einen linearen Adressraum, der aus bis zu 2 32 Bytes (4 GByte) besteht. Mit Paging und Segmentierung besitzt IA 32 zwei orthogonale Mechanismen zur Virtualisierung von physikalischem Speicher. Der Prozessor arbeitet mit logischen Adressen, die sich aus einem Segmentselektor und einem Offset innerhalb des Segmentes zusammensetzt. Der Selektor ist ein Index in der Globale Descriptor Table (GDT) bzw. in der Local Descriptor Table (LDT), die Segmentdeskriptoren speichern. Ein Segmentdeskriptor enthält die lineare Adresse der Segmentbasis und die Größe ( Limit ) des Segments. Die Segmentierungseinheit des Prozessors berechnet im 32 Bit Modus die lineare Adresse aus der Summe der Segmentbasis und dem Offset Anteil der logischen Adresse 3. Beim Paging bestimmt eine MMU ( Memory Management Unit ), wie lineare Adressen mittels einer als Baum organisierten Seiten Kachel Tabelle auf physikalische Adressen abgebildet werden. Segmentierung ist immer aktiv, die Verwendung von Paging ist aber optional und muss explizit angeschaltet werden. Bei deaktiviertem Paging sind lineare und physikalische Adressen identisch. Üblicherweise verwenden Betriebssysteme einen flachen Adressraum, das heißt, Segmente haben die Basisadresse 0 und ein Limit von Byte. Somit sind 3 Es sei angemerkt, dass im Real Mode Segmente anders definiert sind und anders verwendet werden, siehe [Int06a].

25 3.3. SPEZIALREGISTER 13 logische und lineare Adressen identisch und lediglich Paging wird zur Unterteilung und Virtualisierung des physikalischen Speichers genutzt. Im Long Mode ist Segmentierung zwar aktiviert, es ist aber nur ein flacher Adressraum erlaubt Register Acht Allzweckregister, sechs Segmentregister, das Statusregister und das Programmzähler Register ( Program Counter, PC) bilden den Kern der Laufzeitumgebung, die Basis Laufzeitumgebung. Der Großteil der Instruktionen der IA 32 arbeiten mit diesen Registern. Es existiert noch eine Anzahl Spezialregister für Ressourcen Verwaltung, und Steuerung des Prozessors (siehe 3.3) x87 FPU und MMX/XMM Register Die x87 FPU besitzt einen eigenen Satz von Registern. Dazu gehören unter anderem acht Datenregister, ein Kontrollregister, ein Statusregister, ein Programmzähler und ein Opcode Register. Diese bilden eine eigene Laufzeitumgebung für Operationen auf Fließkommazahlen mit unterschiedlicher Präzision, Ganzzahlen unterschiedlicher Größe und Zahlen im BCD Format. Die MMX- und XMM Register bilden jeweils spezielle Laufzeitumgebungen für SIMD Operationen ( single instruction, multiple data ) auf 64 und 128 Bit große Zahlentypen Stack Der Stack und die Stack Verwaltung sind Ressourcen zur Unterstützung von Funktionsaufrufen und der Parameterübergabe zwischen Funktionen. Der Stack befindet sich im Speicher, der Stack Zähler in einem eigenen Register. 3.3 Spezialregister IA 32 besitzt eine Satz von Registern, die für Speicherverwaltung und Steuerung des Prozessors verwendet werden. Da diese Register Ressourcen des Prozessors verwalten, gehören Instruktionen, die auf diese Register zugreifen, zu einer Klasse von Instruktionen, die bei Virtualisierung gesondert behandelt werden müssen. Diese Klasse von Instruktionen werden in den Kapiteln 4 und 5 genauer untersucht Prozessorstatuswort Das Prozessorstatuswort (PSW) ist in dem so genannten EFLAGS Register gespeichert. Es enthält Status Flags, ein Kontroll Flag und System Flags. Die Status Flags signalisieren das Ergebnis von arithmetischen Operationen und das

26 14 KAPITEL 3. IA 32 LAUFZEITUMGEBUNG Kontroll Flag bestimmt, ob bei String Operationen automatisch inkrementiert oder dekrementiert werden soll. Diese Flags können jederzeit modifiziert werden. Die System Flags jedoch dürfen nicht von Benutzerprogrammen modifiziert werden, da sie Funktionen des Prozessors kontrollieren. Zum Beispiel wird über das Interrupt Flag bestimmt, ob der Prozessor auf Interrupts reagiert oder nicht Register für Deskriptortabellen IA 32 Prozessoren besitzen vier Register, die die Basisadressen von Deskriptortabellen beinhalten, die von der Segmentierungseinheit verwendet werden. Dies sind die Register GDTR, LDTR, IDTR und TR. GDTR Das Global Descriptor Table Register (GDTR) speichert die physikalische Adresse von Byte 0 der Global Descriptor Table (GDT) und deren Größe (auch als Limit bezeichnet) in Bytes. Die Adresse ist ein 32 Bit, die Größe ein 16 Bit Wert. Die Instruktionen lgdt und sgdt laden bzw. speichern das GDTR. LDTR Das Local Descriptor Table Register (LDTR) speichert den 16 Bit Segmentselektor, die 32 Bit Basisadresse und das 16 Bit Limit der Local Descriptor Table (LDT). Wie bei der GDT bezeichnet die Basisadresse die physikalische Adresse des Bytes 0 der LDT und das Limit die Tabellengröße in Bytes. Die Befehle lldt und sldt laden bzw. speichern den Segmentselektor der LDT. Beim Laden holt der Prozessor die Basisadresse und das Limit aus dem durch den Segmentselektor bezeichneten und in der GDT gespeicherten Segmentdeskriptor. Der Befehl sldt sichert nur den Segmentselektor, die Basisadresse, Limit und Attribute werden nicht gesichert. Diese Werte sind zwar über die GDT rekonstruierbar, wurde die GDT aber nach dem letzten Laden des LDTR modifiziert, sind diese Werte verloren. IDTR Wie das GDTR enthält das Interrupt Descriptor Table Register (IDTR) die lineare 32 Bit Adresse von Byte 0 der Interrupt Descriptor Table (IDT) und deren 16 Bit Limit. Die Befehle lidt und sidt laden bzw. speichern das IDTR. TR Das Task Register (TR) speichert den 16 Bit Segmentselektor, die 32 Bit Basisadresse und das 16 Bit Limit des Task State Segments (TSS) des gerade

27 3.3. SPEZIALREGISTER 15 aktiven Tasks. Die Befehle ltr und str laden bzw. speichern den Segmentselektor des TSS. Wie beim Befehl lldt, holt der Prozessor beim Laden des TR die Basisadresse und das Limit aus dem durch den Segmentselektor bezeichneten und in der GDT gespeicherten Segmentdeskriptor. Der Befehl str sichert den Tasksegmentdeskriptor Segmentregister Eine Reihe von Segmentregistern definieren, in welchen Segmenten Code und Daten liegen. Die Register enthalten einen Index, den so genannten Segmentselektor, der einen Eintrag aus der GDT bzw. LDT bezeichnet. Code wird immer aus dem vom Codesegmentregister CS bezeichnetem Segment gelesen. Speicherzugriffe auf Daten können auf vier verschiedene Segmente abgebildet werden, die mit den Registern DS, ES, FS und GS definiert werden. Das von DS definierte Segment wird automatisch verwendet, wenn bei einem Speicherzugriff keines der anderen Segmente explizit angegeben wird. Der Stack liegt immer in dem von SS bezeichnetem Segment Kontrollregister IA 32 besitzt fünf Kontrollregister, die Modus und Eigenschaften des Prozessors steuern. Die Kontrollregister werden mit CR0, CR1, CR2, CR3 und CR8 bezeichnet, wobei CR8 nur im Long Mode vorhanden ist. CR0 CR0 steuert Funktionen, die auf allen IA 32 System verfügbar sind. Dazu gehören: An-/Abschalten des Protected Mode Interaktion mit der FPU bzw. deren Emulation An-/Abschalten von Caches bzw. Caching Strategien An-/Abschalten des Alignment Checkings An-/Abschalten des Pagings Ein Teil dieser Funktionen sind nur im Protected Mode verfügbar. CR1 Dieses Register ist reserviert und darf nicht verwendet werden.

28 16 KAPITEL 3. IA 32 LAUFZEITUMGEBUNG CR2 Bei einem Pagefault wird die verursachende lineare Adresse im Register CR2 gespeichert und so dem anschließend aufgerufenen Exceptionhandler verfügbar gemacht. CR3 Bei aktiviertem Paging enthält CR3 die Basisadresse des Pagedirectories. Da das Pagedirectory an einer Seitengrenze beginnen muss, werden nur die oberen 20 Bit für die Basisadresse verwendet. Von den unteren zwölf Bit sind zehn reserviert und zwei (die Bits drei und vier) kontrollieren das Caching der Pagedirectory Seite. CR4 Dieses Register steuert architekturabhängige Funktionen der CPU, die nicht auf allen Prozessoren der IA 32 Familie verfügbar sind. Dazu gehören: CR8 An-/Abschalten des virtuellen 8086 Modus An-/Abschalten des Time Stamp Counters (Taktzyklenzähler, TSC) An-/Abschalten der Debuggingregister Steuerung der Page Size Extension und Page Address Extension (PSE und PAE) An-/Abschalten von globalen Seiten Das Register CR8 ist nur im Long Mode der Prozessoren der IA 32e Familie vorhanden. Es enthält die aktuelle Task Priorität, die angibt, welche Hardwareinterrupts momentan erlaubt sind. In Verbindung mit einem I/O APIC ist die Umsetzung eines auf Prioritäten basierten Interruptsystems möglich. 3.4 Prozessor Modi IA 32 Prozessoren haben drei Betriebsmodi, die bestimmen, welche Instruktionen und Funktionen des Prozessors nutzbar sind (siehe [Int06a], Kapitel 3). Die Modi heißen Real Address Mode (kurz Real Mode ), Protected Mode und System Management Mode (SMM). Mit AMD64 bzw. Intel 64 kommt noch ein weitere Modus hinzu, der Long Mode.

29 3.4. PROZESSOR MODI 17 Der Real Mode bietet die gleiche Ausführungsumgebung wie der 8086 Prozessor, der Vorläufer der IA 32 Prozessoren, besitzt aber zusätzlich die Möglichkeit, in den Protected Mode zu schalten. Obwohl IA 32 Prozessoren beim Einschalten bzw. nach einem Reset im Real Mode starten, ist der Protected Mode der hauptsächlich verwendete Betriebsmodus. In ihm stehen 32 Bit Adressierung, Paging und Speicherschutz ( Protection ) zur Verfügung, alles Mechanismen, die zur Implementierung von Multitasking benötigt werden. Daher arbeiten nahezu alle modernen Betriebssysteme auf IA 32 Prozessoren im Protected Mode. Der Virtual 8086 Mode (VM86) ist ein spezielles Attribute für Tasks des Protected Modes. Wird es für einen Task gesetzt, können Programme für den Real Mode in diesem Task ausgeführt werden. Der System Management Mode (SMM) erlaubt es einem Betriebssystem oder der Firmware durch einen externen Interrupt in einen separaten Adressraum zu schalten. Dies geschieht vollständig transparent und erlaubt es unter anderem, bestimmte Power Management Funktionen (zum Beispiel Suspend to Disk ) zu realisieren Schutzmodell des Protected Mode Der Protected Mode besitzt ein auf Ringen basierendes Schutzmodell. Dieses beruht auf vier Privilegierungsstufen, die als Ringe bezeichnet werden. Ring 0 ist am meisten und Ring 3 am wenigsten privilegiert. Abhängig von der Privilegierungsstufe werden privilegierte Instruktionen 4 erlaubt oder verboten, Adressräume konfiguriert und der Zugriff auf I/O Geräte kontrolliert. Der Prozessor kontrolliert den Datenfluss zwischen Ringen anhand von Privilegierungsstufe, die mit CPL, DPL und RPL bezeichnet werden. Die aktuelle Privilegierungsstufe eines Rings wird als Current Privilege Level (CPL) bezeichnet und wird durch den Wert der Bits 0 und 1 des Code- und Stack Segment Register festgelegt. Diese Bits eines Selektors werden als Requested Privilege Level (RPL) bezeichnet. Die Privilegierungsstufe eines Segmentdeskriptors wird mit Descriptor Privilege Level (DPL) bezeichnet und im DPL Feld des Deskriptor definiert. Diese drei Privilegierungsstufen werden beim Laden von Segmentregistern und bei Speicherzugriffen von der CPU auf Konsistenz überprüft, wodurch das Schutzmodell der Ringe umgesetzt wird. Würden Daten von einem höher privilegierten Ring in einen niedriger privilegierten Ring fließen, erzeugt der Prozessor eine Exception. Details zu diesem komplexen Schutzmodell finden sich in [Int06d, Thi88]. Ein Betriebssystemkern läuft üblicherweise im Ring 0, da er vollen Zugriffe auf alle privilegierten Instruktionen, Speicherverwaltungsmechanismen und I/O Geräte braucht. Entsprechend laufen unprivilegierte Benutzerprogramme im Ring 3. 4 Die Bedeutung von privilegierten Befehlen wird in Abschnitt 4.3 genau definiert.