Der Xen-Hypervisor. Hauptseminar: Systemvirtualisierung. Michael Weiß. Fakultät für Informatik, Technische Universität München

Transkript

1 Der Xen-Hypervisor Hauptseminar: Systemvirtualisierung Michael Weiß Fakultät für Informatik, Technische Universität München Zusammenfassung Diese Arbeit befasst sich mit grundlegenden Architekturen des Xen-Hypervisors, welcher ursprünglich an der Universität Cambridge entwickelt wurde und mittlerweile in Version 3 vorliegt. Es wird ein Einblick in die Interna dieses Hypervisors gegeben, wie die einzelnen Virtualisierungsstrategien bezüglich Hauptprozessor, Speicher und I/O-Devices umgesetzt sind. 1 Einleitung Xen wurde 2003 erstmals von Baham et al. [DFH + 03] an der Universität Cambridge vorgestellt. In seiner ersten Version ermöglichte der Xen-Hypervisor durch Paravirtualisierung auf der IA-32/x86-Architektur, verschiedene virtuelle Maschinen parallel zur Ausführung zu bringen, um somit mehrere Betriebssysteme gleichzeitig auf einer realen Maschine betreiben zu können. Der Xen-Hypervisor ist ein Virtual-Machine-Monitor (VMM), der zwischen Hardware und Betriebssystem eine Abstraktionsschicht darstellt. Die Bezeichnung Hypervisor wurde gewählt, weil er höher privilegiert ist als der Supervisor, also der Kernel des Betriebssystems. Paravirtualisierung bedeutet, dass ein Gastbetriebssystem, welches unter Kontrolle des VMM laufen soll, angepasst werden muss und in gewisser Weise somit über die Existenz des VMM Bescheid wissen muss. Im Gegensatz zur Paravirtualisierung steht die Vollvirtualisierung, mit welcher der Einsatz von unmodifizierten Gastbetriebssystemen möglich ist Im Vergleich zu den zu diesem Zeitpunkt üblichen Vitualisierungslösungen auf der IA-32-Architektur wie VMware Workstation, welche für problematische CPU- Instruktionen eine Technik genannt Binary-Translation einsetzen, ist der Xen-Ansatz wesentlich performanter. Einen Überblick über diese Techniken liefern Rosenblum et al. [RG05]. In neueren Xen-Implementierungen ab Version 3 ist nun auch die Möglichkeit gegeben, ein unmodifiziertes Gastbetriebssystem zu betreiben. Dies ist allerdings nur durch eine Hardwaremodifikation seitens der CPU-Hersteller [DLN + 06] ermöglicht worden, die einen speziellen Ausführungsmodus für den Hypervisor zur Verfügung stellt. 2 Xen Design und Architektur Xen ist kein typischer Hypervisor im Vergleich zu einem traditionellen Hypervisor, bekannt aus der IBM Mainframe-Serie. Dort ist die virtuelle Hardware identisch mit der darunterliegenden echten Hardware, was man auch als Vollvirtualisierung bezeichnet. Dies bietet zwar den Vorteil, dass unmodifizierte Betriebssysteme direkt

2 in einer virtuellen Maschine laufen, aber ist nicht auf jeder Hardware-Plattform umsetzbar. Die IA-32-Architektur von Intel, für die Xen ursprünglich entwickelt wurde, ist nicht dafür ausgelegt nach Popek und Goldberg [PG73] vollvirtualisiert zu werden. Popek und Goldberg definieren hierzu folgende drei Kategorien von Prozessorinstruktionen: 1. Privilegierte Instruktionen: Diese Instruktionen können nur im privilegierten Modus ausgeführt werden. Wenn solch eine Instruktion im unprivilegierten Anwendungsmodus ausgeführt wird, erzeugt dies einen Trap Verhaltens-sensitive Instruktionen: Dies sind Instruktionen die sich in Abhängigkeit von der derzeitigen Ressourcen-Konfiguration unterschiedlich verhalten, z. B. Speicheroperationen zum Laden und Schreiben. 3. Kontroll-sensitive Instruktionen: Diese Instruktionen verändern den Ressourcen-Zustand des Systems, z. B. Laden der Pagetables oder das Ändern globaler Kontrollregister. Für eine vollvirtualsierbare Prozessorarchitektur müssen alle sensitiven Instruktionen auch privilegierte Instruktionen sein. Allerdings gibt es in der IA-32-Architektur einige sensitive Instruktionen die nicht privilegiert sind. Diese werden auch als kritische Instruktionen bezüglich der Virtualisierbarkeit bezeichnet. Somit gibt es Instruktionen welche, wenn sie in einer unprivilegierten Sicherheitsstufe ausgeführt werden, still fehlschlagen, ohne einen Trap auszulösen. Diese können folglich nicht vom VMM abgefangen werden. Deshalb geht Xen den Weg der Paravirtualisierung. Hier wird eine virtuelle Maschine, die nur ähnlich zu der echten Hardware ist, zur Verfügung gestellt. Dadurch ergeben sich Performancegewinne im Vergleich zu der Emulation echter Hardware, aber auch der Nachteil, dass ein Gastbetriebssystem nicht unmodifiziert einsetzt werden kann. Die Modifikation beschränkt sich hierbei auf den Kernel des Gastes, die ABI 2 für die Userspace-Anwendungen bleibt erhalten und somit kann jede Anwendung ohne Modifikation auch in der paravirtuellen Maschine eingesetzt werden. Allerdings ist die Modifikation des Gastkernels nicht immer möglich, vor allem dann nicht wenn die Quellen des Gastbetriebssystems nicht verfügbar sind. Somit ist z. B. der Einsatz eines der meist verwendeten Betriebssysteme, Microsoft Windows, in Xen langezeit nicht möglich gewesen. Erst die Einführung der sogenannten HVMs (siehe Kapitel 2.3) verschaffte hier Verbesserung. Den Weg der Paravirtualisierung, wie ihn Xen geht, birgt einige Besonderheiten. So ist die Trennung der Sicherheitsstufen nicht strikt durchgehalten zwischen Hypervisor, Gastkernel und Userspace-Anwendungen. So ermöglicht Xen durch diverse Shared-Memory-Konzepte hier eine gewisse Aufweichung der strikten Trennung von den einzelnen Sicherheitsschichten in vertikaler Richtung zwischen Hypervisor und Gastkernel sowie die direkte Abschottung der einzelnen Gastsysteme in horizontaler Richtung. Nativ auf der Plattform ausgeführt läuft der Kernel in einer höheren Sicherheitsstufe als der Rest der Anwendungen. Die IA-32 Architektur stellt hier vier Sicherheitsstufen, sogenannte Ringe von 0 bis 3, zur Verfügung. Ring 0 ist die am höchsten privilegierte Sicherheitsstufe, während Ring 3 die niedrigste Sicherheitsstufe darstellt. Deshalb wird auf einem nativen IA-32-System der Kernel in Ring 0 1 Synchrone Unterbrechung, welche durch eine Ausnahme in der Anwendung ausgelöst wird um dann im Kernelmodus behandelt zu werden. 2 Application-Binary-Interface: Schnittstelle für Anwendungen zum Betriebssystem mit Systembibliothek 2

3 Abbildung 1: Vergleich Sicherheitsstufen (Ringe) in nativen und paravirtualisierten Systemen auf der IA-32-Architektur (entnommen aus [Chi07]) und die Anwendungen in Ring 3 ausgeführt. Die Ringe 1 und 2 werden in der Regel nicht benutzt, da sich viele Betriebssysteme aus Portabilitätsgründen auf zwei Sicherheitsstufen Beschränken. Nun muss Xen aber höher privilegiert sein als die Kernel der Gastsysteme, da der Hypervisor diese von einander abschotten muss. Somit werden die Gastkernel auf Ring 1 verschoben, was auch Abbildung 1 verdeutlicht. Mittlerweile unterstützt Xen aber auch andere Architekturen wie z. B. AMD64 oder IA-64 (Itanium) [PFH + 05] 2.1 Privilegierte Domäne (Dom0) Xen stellt virtuelle Maschinen für seine Gäste bereit, die sogenannten Domänen. Der erste Gast läuft immer in der Domäne 0 (Dom0), die eine gewisse Sonderposition gegenüber den anderen Domänen den DomUs (unprivilegierten Domänen) einnimmt. Diese Sonderposition begründet sich damit, dass Xen selbst keine Gerätetreiber bzw. Benutzerschnittstellen bereitstellt. Dem Betriebssystem in Dom0 wird daher Zugriff auf die Hardware gegeben, damit die dortigen Treiber und Benutzerschnittstellen von Xen genutzt werden können. In der Regel läuft hier ein Linux System, allerdings gibt es mittlerweile auch eine NetBSD- sowie eine OpenSolaris-Portierung. Hauptaufgabe der Dom0 ist das Multiplexen der Gerätezugriffe aus den anderen Domänen und sich selbst. Hier lässt sich schon erkennen, dass diese Dom0 speziell zu schützen ist, da sie uneingeschränkten Zugriff auf die Hardware hat. Aus Sicherheitsgründen sollten deshalb so wenig wie möglich Dienste in Dom0 ausgeführt werden, sondern in DomUs oder HVMs (siehe weiter unten). Durch einen erfolgreichen Angriff auf Dom0 könnten sonst prinzipiell alle virtuellen Maschinen des Systems kompromittiert werden. 3

4 2.2 Unprivilegierte Domäne (DomU) DomUs sind die Domänen in denen die eigentlichen Gastsysteme laufen. Dies sind besser abgeschottet als die Dom0, welche im Prinzip Bestandteil des VMM ist. In DomUs kann nicht direkt auf die Hardware zugegriffen. Stattdessen verwenden die Betriebssysteme in einer DomU spezielle Treiber für virtuelle Geräte. Sie müssen das Frontend des sogenannten Split-Device-Treibers implementieren, dazu später mehr in Kapitel 5. Aber auch hier ist eine gewisse Aufweichung der Abschottung möglich, da es auch in DomUs explizit erlaubt werden kann auf spezielle Geräte direkt zu zugreifen. So kann man z. B. PCI-Geräte direkt an eine DomU durchreichen. Allerdings kann dann in Dom0 dieses Gerät nicht mehr verwendet werden. 2.3 Hardware-Virtuelle-Maschine (HVM) Seit die CPU-Hersteller Virtualisierungserweiterungen in ihre IA-32/AMD64-Prozessoren integriert haben, ist es Xen auch möglich, unmodifizierte Betriebssysteme vollvirtualisiert zu betreiben. Dies geschieht in sogenannten HVMs. Hier läuft der Hypervisor in einem noch höher privilegierten Ring -1, wobei der Gastkernel weiterhin in Ring 0 verweilt. Durch die Einführung der HVMs [PFH + 05] wurde erstmals der Einsatz von Windows als Gast ermöglicht. Ein unmodifiziertes Betriebssystem hat keine Unterstützung für die Xen Split- Device-Treiber, weshalb Xen hier ausgewählte Komponenten emuliert, die der Gast unterstützt. Einige Geräte, z. B. eine NE2000-Netzwerkkarte, sind auf diese Weise verfügbar. Der Quellcode hierfür kommt aus dem QEMU-Projekt. Abbildung 2: Struktur einer Maschine, welche den Xen-Hypervisor ausführt. (entnommen aus [Chi07]) 4

5 3 CPU-Virtualisierung Normalerweise läuft das Betriebssystem auf der höchsten Sicherheitsstufe. Durch das Einführen eines Hypervisors ist dies nicht mehr möglich. Dieser muss höher privilegiert sein, als die verschiedenen Betriebssysteminstanzen, welche gleichzeitig auf dem selben System von einander abgeschottet laufen sollen. Viele Prozessoren bieten hierfür aber nur zwei Sicherheitsstufen. Auf solchen Architekturen, z. B. AMD64, müssen die Kernel der Gäste auf der niedrigeren Stufe zusammen mit den Anwendungen laufen. Innerhalb des Gastes wird der Kernel von seinen Anwendung durch einen separaten Adressraum abgeschottet. Der Wechsel der Adressräume wird indirekt über den Hypervisor geregelt. Xen wurde aber hauptsächlich für die IA-32 Architektur entwickelt, die wie oben schon erwähnt, vier Sicherheitsstufen, Ring 0 bis Ring 3, in Hardware unterstützt. Die meisten Betriebssysteme für IA-32 nutzen nur Ring 0 als höchst privilegierte Sicherheitsstufe für den Kernel und Ring 3 als unpriviligerte Sicherheitsstufe für die Anwendungen. Ausnahme hiervon ist OS/2, was aber kaum mehr eingesetzt wird. Bei OS/2 wurden Gerätetreiber in Ring 1 geladen, um den Kernel vor fehlerhaften Treibern zu schützen. Also steht aus heutiger Sicht Ring 1 und Ring 2 zur freien Verfügung. Xen macht sich dies zu Nutze um effizient den Hypervisor höher privilegiert als die Gastkernel zu betreiben. Der Hypervisor läuft mit allen Privilegien in Ring 0, während die Gastkernel auf Ring 1 eingeschränkt werden. Die Gastkernel sind aber immer noch von den Anwendungen, die auf Ring 3 bleiben, abgeschottet. 3.1 Paravirtualisierung Der Kernel muss natürlich angepasst werden damit er auf Ring 1 läuft. Ein unmodifiziertes Betriebssystem geht davon aus, dass es privilegierte Instruktionen im Kernelmodus direkt ausführen kann, was in Ring 1 nicht geht. Vor allem gibt es einige sensitiven Operationen in der IA-32-Architektur die keine Ausnahme verursachen, welcher von einem Handler im Kernel abgefangen werden kann, wenn diese Operationen aus einem weniger privilegierten Ring ausgeführt werden (siehe Kapitel 2). Diese nach Popek und Goldberg kritischen Operationen müssen also im Gastkernel ersetzt werden, durch einen Mechanismus, der vorher in den Hypervisor wechselt und dort die kritische Operation entweder ausführt oder durch andere ersetzt. So sollte z. B. ein Systemhalte-Befehl von einem Gast nicht direkt durchgereicht werden, sonst würden alle anderen virtuellen Maschinen ebenfalls abgeschaltet. 3.2 Hypercalls Es braucht einen Mechanismus, um kontrolliert in den Hypervisor zu wechseln und wieder zurück in den Gastkernel. Bei einem nativen System gibt es so einen Mechanismus bereits für Anwendungs-Code auf Ring 3, um in den Kernel auf Ring 0 zu wechseln. Um auf Hardware zuzugreifen, z. B. Anzeige auf dem Bildschirm, gibt es die Systemaufrufe (Syscalls). Durch Syscalls ist es der Anwendung möglich dem Kernel zu sagen was er für sie tun soll. Syscalls funktionieren folgendermaßen: 1. Kopieren der Aufrufparameter in Register oder auf den Stack, falls nicht genügend Register für alle Parameter zur Verfügung stehen 2. Wechsel über einen Software-Interrupt oder eine spezielle Syscall-Instruktion in den Systemmodus (Ring 0) 5

6 3. Sprung zu dem Interrupt-Handler im Kernel 4. Ausführen des Systemaufrufs mit Kernelprivilegien 5. Wechsel in die ursprüngliche niedrigere Sicherheitsstufe In Betriebssystemen für IA-32-Prozessoren wird für Systemaufrufe normalerweise der Interrupt 80h benutzt. Neuere Prozessoren dieser Architektur haben allerdings auch die SYSENTER/SYSEXIT Instruktionen, welche über eine gemeinsam genutzte Speicherseite von Ring 3 und Ring 0 ablaufen. Xen führt hier das Konzept der Hypercalls ein, welche wie Syscalls funktionieren, nur zwischen dem Gastkernel und dem Hypervisor anstatt zwischen Userspace- Anwendung und Betriebssystemkern. In den ersten Xen Versionen wurde hier das gleiche Verfahren angewandt, nur wurde der Interrupt 82h anstatt 80h verwendet. Seit Xen Version 3.0 ist die Benutzung des Interrupt 82h als deprecated bezeichnet. Dafür wird eine spezielle Speicherseite, die Hypercall page, zur indirekten Ausführung der Hypercalls verwendet. Diese wird beim Start einer Gastmaschine in dessen Adressraum eingeblendet. Ein Hypercall wird ausgeführt, indem man an eine Adresse auf dieser Seite mit einem gewissen Offset springt, ähnlich dem Syscall-Verfahren mit den SYSENTER/SYSEXIT Instruktionen. Abbildung 3: Systemaufruf in nativer und paravirtualisierter Umgebung (entnommen aus [Chi07]) Abbildung 3 stellt den Unterschied dar und zeigt, wie ein Systemaufruf aus Ring 3 auf einem nativen System sowie auf einem paravirtualisierten System aussieht. Die Interrupt-Handler befinden sich hier in Xen und nicht im Gastkernel. Wenn also der Interrupt 80h ausgelöst wird, springt die Ausführung in den Hypervisor und gibt dann die Kontrolle zurück an den Gastkernel. Diese zusätzliche Indirektion verursacht natürlich einen kleinen Performanceverlust, aber dadurch ist es möglich unmodifizierte Anwendungen auszuführen. Xen stellt auch einen Mechanismus für 6

7 direkte Systemaufrufe ohne Umweg über den Hypervisor bereit, diese Fast-System- Calls setzten aber eine geänderte libc voraus. Wie bei Syscalls gibt es auch für Hypercalls Makros, die der Kernelentwickler benutzen kann, z. B. für Scheduling Operationen den HYPERVISOR sched op (siehe Abbildung 3.2). s t a t i c i n l i n e int HYPERVISOR sched op ( int cmd, unsigned long arg ) { return h y p e r c a l l 2 ( int, sched op, cmd, arg ) ; } Abbildung 4: Hypercall-Inline-Funktion mit 2 Parametern, welche das hypercall2- Makro nutzt Um zum Beispiel die virtuelle Maschine in einen niedrigeren Power-Level zu schalten, wird im Gastsystem nicht die hlt Instruktion benutzt, sondern der Hypercall HYPERVISOR sched op mit SCHEDOP ylied als Argument. 4 Speicherverwaltung Speicherverwaltung ist sehr von der Prozessorarchitektur abhängig. So besitzt der IA-32-Prozessor in Hardware eine Memory-Management Unit (MMU), welche sich um Adressübersetzungen zwischen virtuellen und physikalischen Adressen kümmert. Ein SPARC-Prozessor hat keine MMU, sondern stellt nur einen TLB 3 zur Verfügung, während die Pagetables in Software verarbeitet werden müssen. Hier wird nun hauptsächlich auf die IA-32-Architektur eingegangen. 4.1 Pseudo-Physical Memory-Model In Bezug auf Speichermanagement gibt es nun schon lange das Prinzip des virtuellen Speichers, welches einer Applikation einen exklusiv für sie zur Verfügung stehenden Adressraum präsentiert. Das Betriebssystem kümmert sich mit Hilfe der MMU des Prozessors oder in Software um die Übersetzung von virtuellen zu physikalischen Adressen. Xen muss nun eine ähnlich Umsetzung der Speicheradressen für die Gastmaschinen durchführen, d.h. es muss also eine Indirektionsschicht zwischen virtuellen und physikalischen Adressen eingeführt werden, eine mit pseudo-physikalischen Adressen. Dies zeigt Abbildung 5 VMware führte hierfür das Prinzip der Shadow-Pagetables ein. Bei diesem Prinzip gibt es eine virtuelle Pagetable, welche der MMU gegenüber unsichtbar ist. Jeder Zugriff auf diese wird dann durch den Hypervisor abgefangen. Der Hypervisor kümmert sich nach einer Validierung um die Weiterleitung auf die, der MMU sichtbaren Pagetable (Shadow-Pagetable) und zurück. Dieses Vorgehen erhöht allerdings den Aufwand für Speicherzugriffe in den Gastsystemen, was aber leider für Vollvirtualisierung notwendig ist, um den Gast einen vollständig zusammenhängenden physikalischen Speicher vorzuspielen. 3 Translation-Lookaside-Buffer: Puffer von Adressübersetzungen zwischen virtuellen und physikalischen Adressen 7

8 Abbildung 5: Die drei Stufen des Xen-Speichersystems (entnommen aus [Chi07]) Xen bietet hier eine performantere Lösung als die Shadow-Pagetables. Der Xen- Ansatz für paravirtualisierte Gäste ist, dass die Gastbetriebssysteme direkt ihre Pagetables in der MMU registrieren. Dadurch fällt ein Indirektionsschritt weg. Allerdings muss Xen die Kontrolle über Updates der Pagetable behalten, um unrechtmäßige Änderungen durch das Gastbetriebssystem zu unterbinden. Dazu wird die Pagetable read-only für den Gast markiert und Schreibzugriffe werden über einen Hypercall an Xen durchgereicht. Im Hypervisor wird dann entschieden ob der Zugriff rechtmäßig ist oder nicht. Wenn ja wird dieser von Xen auf die Pagetable angewandt. Im Falle einer HVM nutzt Xen auch eine Implementierung der Shadow-Pagetables, da durch die neueren Virtualisierungserweiterungen die IA-32/AMD64-Prozessoren dies auch in Hardware unterstützen. 4.2 Der Balloon-Treiber Xen teilt den physikalischen Arbeitsspeicher statisch zwischen den Domänen auf, um eine starke Isolierung zu gewährleisten, d. h. der reale Arbeitsspeicher wird partitioniert und eine Partition wird als pseudo-physikalischer Speicher genau einer Domäne zugeordnet. Wie viel pseudo-physikalischer Speicher einer Domäne zur Verfügung steht, wird bei ihrer Erstellung festgelegt. Dies bedeutet, dass eventuell in einer Maschine zu einem späteren Zeitpunkt zu wenig pseudo-physikalischer Speicher bereit steht, während vom tatsächlich vorhandenen physikalischen Arbeitsspeicher noch genügend frei währe, dieser aber in anderen Partitionen gebunden ist. Einen Ausweg aus diesem Dilemma bietet Xen in Form des sogenannten Balloon- Treibers. Durch diesen ist es möglich, dass eine Domäne ungenutzten Speicher in gewisser Weise an Xen zurückgibt, damit dieser von einer anderen Domäne genutzt werden kann. Dies erfordert die Kooperation des Gastbetriebssystems, damit es den freien pseudo-physikalischen Speicher für Xen reserviert. Außerdem sollte eine volle Implementierung des Balloon-Treibers eine Variable im XenStore 4 überwachen, die den aktuellen Wert des zugewiesenem Arbeitsspeichers enthält. Dies kann in Dom0 durch einen Administrator gesetzt werden. 4 Der XenStore ist eine gemeinsam genutzte Datenbank von allen Domänen mit Konfigurationsdaten, welche von der Dom0 gepflegt wird 8

9 Dies bedeutet natürlich auch eine gewisse Aufweichung der starken Isolation zwischen den Domänen, denn aus Kernelsicht des Gastes bleibt der Speicher im System vorhanden, er wird nur vom Balloon-Treiber belegt, der Ihn dann an den Hypervisor zurückgibt. Dies ist auch der Grund, warum eine Domäne nicht mehr als den ursprünglich maximal, beim Erstellen der Domäne, eingestellten Arbeitsspeicher vom Balloon-Treiber anfordern kann. Der Balloon ist in Abbildung 6 visualisiert. Diese ist aus einem Informationshandbuch zu VMware ESX 3 entnommen. Der VMware ESX Hypervisor nutzt ebenfalls die Balloon-Technik und Xen hat sie von dort übernommen. Abbildung 6: Balloon-Treiber in Aktion (entnommen aus [VMw06]) 5 I/O-Device-Virtualisierung Gerätetreiber sind sehr wichtig für jedes Betriebssystem, denn ohne sie könnte der Kernel und somit auch die Anwendungen nicht mit der an das System angeschlossenen Hardware kommunizieren. In vollvirtualisierten Umgebungen werden Hardware-Devices emuliert, d.h. es wird ein tatsächlich existierendes Gerät vollständig in Software nachgebildet. Somit kann im Gast der Treiber für das wirklich existierende Gerät verwendet werden. In QEMU z. B. wird eine NE2000-Netzwerkkarte emuliert. In der virtuellen Maschine kann dann der NE2000-Treiber benutzt werden, obwohl gar keine NE2000-Hardware vorhanden ist. Dies ist eine akzeptable Lösung für Gäste die vollvirtualisiert laufen. So wird auch in Xen für HVM-Domänen Hardware-Emulation eingesetzt. Im paravirtualisierten Fall fällt die Notwendigkeit weg, vorhandene Treiber zu benutzen, da das Betriebssystem angepasst werden muss. Allerdings soll der Aufwand Xen-Geräte zu implementieren, auch nicht zu hoch sein, weil sie in den Gastkernel eingebaut werden müssen. Außerdem sollten sie schneller sein als emulierte 9

10 Geräte, da sonst kein Vorteil darin besteht, vor allem aus Sicht des Gastkernelentwicklers. Xen stellt deswegen abstrakte Geräte bereit, welche High-Level-Schnittstellen zu einer gewissen Geräteklassen bieten. Also anstatt einer IDE-Festplatte wird einem Gastkernel ein abstraktes Block-Device präsentiert, welches nur zwei simple Operationen unterstützt, nämlich lesen und schreiben eines Blocks. Dies erhöht die Performance ungemein, weil nicht erst im Gast die Daten auf hoher Abstraktionsebene in niedrigere Hardware-Instruktionen umgewandelt werden, welcher der Hypervisor wieder in höhere, logische Befehle umwandeln muss, damit er sie an den Device-Treiber weitergeben kann, der diese wieder auf Hardware- Instruktionen abbildet. 5.1 Split-Driver-Model Wie bereits erwähnt, hat Xen selbst keine Gerätetreiber. Statt dessen nutzt Xen die bereits vorhanden Treiber des Dom0-Gastbetriebssystems. Hardware-Unterstützung ist ein Problem, das jeder Hypervisor hat, der die Gerätetreiber selber bereit stellt. So ist z. B. VMware ESX auf gewisse, ausgewählte Hardware-Komponenten beschränkt, während Xen auf jedem beliebigen Rechner läuft, auf dem das Dom0- Gastsystem mit seinen vorhanden Treibern läuft. Da in der Regel Linux in der Dom0 eingesetzt wird, gibt es eine Vielzahl an Treibern, die einem Xen-System zur Verfügung stehen, und das ohne eigenen Implementierungsaufwand. Außerdem müssen die Hardware-Zugriffe der Gastsysteme auf die tatsächlich vorhandene Hardware gemultiplext werden. In heutigen Multitasking-Betriebssystemen ist eine solche Funktionalität bereits für diverse Geräte vorhanden. So können mehrere Anwendungen gleichzeitig die Festplatte oder Netzwerkkarte benutzen, ohne aufeinander Rücksicht zu nehmen. Abbildung 7: Netzwerktreiber in einer Xen-DomU (entnommen aus [Chi07]) 10

11 Dies nutzt Xen ebenfalls aus, um möglichst wenig fehlerträchtigen Code selbst implementieren zu müssen, und führt den Split-Device-Treiber ein. Dieser besteht aus dem sogenannten Frontend-Treiber, der in den einzelnen DomUs läuft und dem zugehörigen Backend-Treiber in Dom0. Seit Version 3 gibt es auch isolierte Treiber- Domänen (IDD), die den Backend-Treiber von dem Dom0-Kernel entkoppeln, und somit eine Möglichkeit bieten die Dom0 vor schlechten Treibern zu schützen. In einer IDD kann der Gerätetreiber keinen Schaden am Kernel der Dom0 anrichten, falls er z. B. durch einen Fehler in Speicherbereiche schreiben will die er nicht verändern sollte. Ebenfalls könnte sich ein Rootkit als Gerätetreiber in den Dom0-Kernel installieren wollen, dies wird durch eine IDD verhindert. Der Backend-Treiber wird über einen Multiplexer mit dem echten Treiber verbunden, der dann den eigentlichen Zugriff auf die reale Hardware durchführt. In Abbildung 7 ist dies beispielhaft für eine Anwendung, welche auf die Netzwerkkarte zugreift, skizziert. Die Anwendung geht über den TCP/IP-Stack des Gastsystems auf den Frontend-Treiber und über den Backend-Treiber auf den TCP/IP- Stack des Dom0-Systems, welches dann die Hardware mit seinem echten Netzwerktreiber anspricht. Im Dom0-System wird einfach der vorhandene Bridging- bzw. Routing-Mechanismus vom Betriebssystem als Multiplexer benutzt. Im Falle einer Linux-Dom0 ist das Iptables oder die Ethernet-Bridge-Tools-Tools im Kernel. Wichtig ist, dass die Xen-Devices nicht wirklich Teil von Xen sind. Der Hypervisor stellt nur eine Kommunikationsverbindung für den geteilten Treiber zur Verfügung. Dies passiert über einen Shared-Memory-Mechanismus, welcher als I/O- Ring-Mechanismus bezeichnet wird. 5.2 I/O-Rings Ein I/O-Ring ist eine zyklische Queue von Deskriptoren. Dieser Ring wird von einer Domäne angelegt, ist aber auch im VMM zugreifbar. In den Deskriptoren sind keine I/O-Daten enthalten. Die eigentlichen Datenpuffer werden außerhalb der Ring- Datenstruktur vom Gastbetriebssystem angelegt und von den I/O-Deskriptoren referenziert. Ein I/O-Ring stellt eine Methode zur asynchronen Kommunikation zwischen Domänen, also virtuellen Maschinen, bereit. Eine Domäne stellt eine Anfrage in den Ring, während eine andere diese Anfrage entfernt und eine Antwort im Ring platziert. Der Zugriff auf den Ring basiert auf zwei Paaren von Zeigern nach dem Produzent/Konsument-Prinzip. Eine Domäne Gast1 stellt Anfragen (Requests) in den Ring, wobei der Request-Producer-Pointer weitergeschalten wird. Ein anderer Gast2 entfernt die Anfragen zur Verarbeitung aus dem Ring, während der zugehörige Request-Consumer-Pointer weitergezählt wird. Die Antworten werden dann von Gast2 wieder auf den Ring platziert in der selben Weise, mit Gast2 als Produzent und Gast1 als Konsument. Die Kommunikation zwischen Xen und einem Gast mittels eines solchen I/O- Ringes mit seinen Zeigerpaaren ist in Abbildung 8 zu sehen. Es ist auch nicht notwendig, dass die Antworten in der selben Reihenfolge wie die Anfragen auf den Ring zurückgestellt werden, da das Gastbetriebssystem jeder Anfrage einen eindeutigen Identifier zuteilt. Somit ist es Xen möglich, I/O-Operation umzuordnen mit Rücksicht auf Priorität und Scheduling. 6 Fazit Xen ist ein performanter Hypervisor durch seinen Paravitualisierungsansatz. Der Split-Device-Treiber ist hier die schnellste Variante mit minimalem Overhead, Geräte aus virtuellen Maschinen heraus anzusprechen. Durch Befehlssatzerweiterungen 11

12 Abbildung 8: Die Struktur von asynchronen I/O-Ringen, welche für den Datenaustausch zwischen Xen und Gastbetriebssystemen verwendet wird (entnommen aus [DFH + 03]) neuerer IA-32-Prozessoren ist es nun auch mit Xen möglich, unmodifizierte Gastbetriebssystem einzusetzen, hier allerdings mit dem Performanceverlust durch die emulierten Gerätetreiber. Aber auch in diesem Bereich geht die Entwicklung weiter und es gibt mittlerweile Ansätze auch in HVM Domänen zumindest einige Geräte mittels nachinstallierbaren Treiben paravirtualisiert mit den Split-Device-Treiber zu beschleunigen. Dies Treiber stehen aber nicht für jedes Gastbetriebssystem zur Verfügung. Die Shared-Memory-Mechanismen und vor allem die Existenz der sehr hoch privilegierten Domäne 0, stellen natürlich auch ein gewisses Risiko in Bezug auf die Sicherheit dar. So ist keine 100%-ige Abschottung der einzelnen virtuellen Maschinen gewährleistet. Die Isolation der virtuellen Maschinen ist bei VMware ESX besser gewährleistet, da hier keine höher privilegierte Domäne existiert, wie die Dom0 bei Xen, da hier die Geräte Treiber im Hypervisor direkt sind. In Bezug auf die Performance gibt es bei VMware ESX mittlerweile auch eine auf Shared-Memory basierte Paravirtualisierung von einigen Geräten, ähnlich dem Split-Device-Treiber. Der Vorteil der guten Treiberunterstützung von Xen durch die Dom0 ist gleichzeitig auch sein größter Nachteil in Bezug auf die Sicherheit. Aber wenn man die Dom0 nicht als virtuelle Maschine ansieht sondern als Teil des Hypervisors, und keine Produktivanwendungen darin laufen lässt, ist die Isolation ausreichend. 12

13 Literatur Chi07. David Chisnall. The Definitive Guide to the Xen Hypervisor. Prentice Hall International, 1 edition, DFH B. Dragovic, K. Fraser, S. Hand, T. Harris, A. Ho, I. Pratt, A. Warfield, P. Barham, and R. Neugebauer. Xen and the art of virtualization. In Proceedings of the ACM Symposium on Operating Systems Principles, October DLN Y. Dong, A. Li, S.and Mallick, J. Nakajima, K. Tian, X. Xu, and W Yang, F.and Yu. Extending xen with intel virtualization technology. Intel Technology Journal, Vol. 10 Issue 3, August FHN Keir Fraser, Steven Hand, Rolf Neugebauer, Ian Pratt, Andrew Warfield, and Mark Williamson. Safe hardware access with the xen virtual machine monitor. In 1st Workshop on Operating System and Architectural Support for the on demand IT InfraStructure (OASIS), October PFH Ian Pratt, Keir Fraser, Steven Hand, Christian Limpach, and Andrew Warfield. Xen 3.0 and the art of virtualization. In Proceedings of the Linux Symposium, volume 2, Ottawa, Ontario, Canada, July PG73. Gerald J. Popek and Robert P. Goldberg. Formal requirements for virtualizable third generation architectures. In SOSP 73: Proceedings of the fourth ACM symposium on Operating system principles, volume 7, New York, NY, USA, October ACM Press. Pra08. Ian Pratt. Xen and the art of virtualization revisited. In Keynote 5th USENIX Symposium on Networked System Design and Implementation (NSDI 08), April RG05. M. Rosenblum and T. Garfinkel. Virtual machine monitors: current technology and future trends. Computer, 38:39 47, VMw06. VMware, Inc. VMware Information Guide - The Role of Memory in VMware ESX Server 3, edition,