Isolation Systemvirtualisierung mit Xen, KVM und NOVA

Transkript

1 Isolation Systemvirtualisierung mit Xen, KVM und NOVA Andreas Trenkmann Universität Dortmund, Dortmund, Deutschland, Zusammenfassung. Diese Arbeit bietet einen Einblick in die Systemvirtualisierung mit XEN, KVM und NOVA. Des Weiteren wird die Eigenschaft der Isolation bei den genannten Systemen eingehend beleuchtet. Dabei werden die Schwächen der jeweiligen genutzten Technologie, Vollvirtualisierung und Paravirtualisierung, aufgezeigt. Die Leistungsfähigkeit der drei Systemvirtualisierungen wird in einer zusammenfassenden Evaluierung gegenübergestellt. 1 Einleitung Augenblicklich ist die Systemvirtualisierung die Grundlage des Cloud-Computings. Betrachtet man die Dienststruktur des Cloud-Computings, so lassen sich die folgenden drei Ebenen identifizieren: Software as a Service (SaaS), Platform as a Service (PaaS) und Infrastructure as a Service (IaaS) [1]. Das letztgenannte IaaS kann man als Verwaltungsebene von Datenzentren verstehen. Diese Datenzentren können aus vielen physikalischen Servern bestehen und noch einer weitaus größeren Anzahl an virtuellen Servern, die sich auf den physikalischen Servern befinden [2]. Die Anzahl der virtuellen Servern ist abhängig von den Ressourcen des physikalischen Hosts. Das IT-Management legt dabei, unabhängig von der Anzahl der virtuellen Maschinen (VMs) je Host, das Hauptaugenmerk auf die Anforderungen an Zuverlässigkeit, Leistungsfähigkeit und Sicherheit [3]. In dieser Ausarbeitung wird die Leistungsfähigkeit und die Sicherheit von den Virtualisierungsumgebungen Xen, KVM und NOVA betrachtet. Dazu werden zunächst die Technologien, die zur Systemvirtualisierung zur Verfügung stehen, erläutert. Anschließend wird als Grundpfeiler der Sicherheit zwischen mehreren VMs, die Isolation zwischen den VMs und zwischen VM und Host-System erklärt. Tiefergehend wird hier die Kompromittierung der VMs und der darüber liegenden Verwaltungsschicht beleuchtet. Daraufhin wird die Leistungsfähigkeit der Virtualisierungsumgebungen gegenübergestellt. Abschließend folgt eine Zusammenfassung der erarbeiteten Erkenntnisse. 2 Systemvirtualisierung Mit Systemvirtualisierung ist man in der Lage, kosteneffektiv, zwei oder mehrere virtuelle Systemumgebungen auf der selben Hardware simultan in Betrieb

2 2 zu nehmen. Dabei können die virtuellen Systemumgebungen aus verschiedenen Betriebssystemen bestehen. Die virtuellen Systemumgebungen werden nachfolgend als Virtual Machine (VM) oder als Gast-Betriebssystem bezeichnet. Hypervisor Eine weitere Grundkomponente der Systemvirtualisierung ist, neben den VMs, der Hypervisor, auch bekannt als Virtual Machine Monitor (VMM). Der Hypervisor agiert als Schicht zwischen dem Gast-Betriebssystem und der echten Hardware. Es wird zwischen zwei Typen von Hypervisors unterschieden. Der Typ 1 Hypervisor läuft direkt auf der System-Hardware, während der Typ 2 Hypervisor auf einem Betriebssystem des Hosts als Anwendung ausgeführt wird, wobei das entsprechende Betriebssystem Virtualisierungsdienste unterstützen muss (vgl. Abbildung 1a und 1b). Somit unterliegt das Gast-Betriebssystem einem der beiden Hypervisor-Typen. Damit hat der Kernel des jeweiligen Gast- Betriebssystems keinen direkten privilegierten Zugriff auf die CPU [3]. Betriebssysteme, obgleich Gast- oder Host-Betriebssysteme, werden durch das (a) Hypervisors vom Typ 1 (b) Hypervisors vom Typ 2 Abb. 1: Einbettung des Hypervisors vom Typ 1 und Typ 2 (entnommen aus [4]) Schutzkonzept der Ringe von Anwendungen abgeschottet. Aus diesem Grund gibt es in der Regel einen privilegierten und einen nicht-privilegierten Modus, diese unterscheiden sich folgendermaßen: Im nicht-privilegierten Modus, dem Benutzermodus (Usermodus), werden üblicherweise die Anwendungen ausgeführt. Im privilegierten Modus, dem Kernelmodus, werden Programmteile des Betriebssystems ausgeführt. Die genannten Modi werden von der CPU unterstütz, dabei wird zwischen der älteren x86-architektur und der aktuellen x64/ia64-architektur unterschieden. In der x86-architektur ist das Schutzkonzept über vier Privilegierungsstufen realisiert, diese Ringe werden vom privilegierten Ring 0 bis zum unprivilegierten Ring 3 hochgezählt. Dabei nutzen proprietäre Betriebssysteme lediglich Ring 0 für das Betriebssystem und Ring 3 für die Anwendungen (vgl. Abbildung 2). Später wird gezeigt, dass bei der x86-architektur die ungenutzten Ringe für die

3 3 Virtualisierung genutzt werden können [5]. Die x64/ia64-architektur hält jeweils nur zwei Ringe vor, die ebenfalls mit Ring 0 (privilegiert) und Ring 1 (weniger privilegiert) bezeichnet werden. Entscheidend Abb. 2: Schutzringe in der x86-architektur (entnommen aus [5]) für die Virtualisierung ist nun die Tatsache, dass nur Prozesse, die in Ring 0 ausgeführt werden, Zugriff auf die Hardware haben. Da proprietäre Betriebssysteme, und damit potenzielle Host-Betriebssysteme, lediglich zwei privilegierte Modi verwenden, muss die VM und damit das Gast-Betriebssystem zusammen mit dessen Anwendungen im unprivilegierten Modus ausgeführt werden. Erfolgt nun durch das Gast-Betriebsystem ein privilegierter Befehl an eine x86-cpu, der eine Ausnahme und damit einen Trap in den höher privilegierten Modus erzeugt, kann dieser Trap von dem Hypervisor nicht abgefangen werden. Ein Trap ist ein Software-Interrupt, der für einen Übergang vom Benutzermodus in den Kernelmodus sorgt, um den aufgerufenen Systemdienst auszuführen. Traps werden üblicherweise durch einen speziellen Maschinenbefehl des Prozessors, den sog. Supervisor-Call oder SVC unterstützt. Der Trap-Mechanismus hat den Vorteil, dass der Aufruf eines Systemcalls von einem Anwendungsprogramm aus ermöglicht wird, ohne dass die tatsächliche Adresse der Systemroutine bekannt sein muss (Information Hiding). Alle Systemcalls zusammen bilden die Schnittstelle der Anwendungsprogramme zum Kernel [6]. Man unterscheidet folgende Befehle, privilegierte und nicht-privilegierte Befehle, sensitive Befehle und kritische Befehle. Zu den sensitiven Befehlen zählen beispielsweise Befehle, die den Zugriff auf Ein- und Ausgabegeräte dienen. Die sensitiven Befehle sind eine sollten eine Teilmenge der privilegierten Befehle sein. Kritische Befehle sind sensitive aber nicht privilegierte Befehle und lösen damit auch keinen Trap aus, somit können sie auch nicht vom Hypervisor abgefangen werden und stellen daher ein Problem dar. Die Schwäche der x86-architektur, des Abfangen von kritischen Befehlen, kann mit derzeitigen Virtualisierungslösungen umgangen werden. Die dazu notwendigen Techniken lauten Code-Patching oder Binärübersetzung (Binary Translation). Dabei werden vor der Ausführung von kritischen Befehlen, selbige vom Hypervisor erkannt und ausgetauscht. Wird nun

4 4 ein solch ausgetauschter Befehl ausgeführt, führt das zum Sprung in den Hypervisor. Dieser hat Zugriff auf Ring 0 und führt den Befehl auf der CPU aus. Diese Vorgehensweise tritt im Hypervisor Typ 2 auf [4]. Die Problematik der kritischen Befehle ist in der x64/ia64-architektur durch saubere Zuordnung der sensitiven zu den privilegierten Befehlen als klare Teilmenge gelöst worden. Virtualisierungstechniken für Prozessoren Seit einiger Zeit haben die Hersteller AMD [7] und Intel [8] die x86-prozessoren um Virtualisierungs-Techniken erweitert. Die Techniken bestehen aus der Erweiterung der Befehlssätze der Prozessoren und der Einführung erweiterter Betriebsmodi. Bei AMD ist die Erweiterung als Pacifica oder AMD-V bekannt und bei Intel heißen die Erweiterungen VMX bzw. Vanderpool. Die Erweiterungen der verschiedenen Hersteller sind zueinander inkompatibel aber relativ ähnlich. Als zusätzliche Modi wurden ein Root- bzw. Wirt-Modus und ein Gast-Modus eingeführt. Der Root-Modus, auch als Ring -1 oder VMX root bekannt, besitzt mehr Privilegien als Ring 0 und besitzt damit die Kontrolle über die CPU und andere Ressourcen. In Ring -1 wird nun auch der Hypervisor ausgeführt. Im Gast-Modus bzw. VMX non-root werden die Gast-Betriebssysteme ausgeführt. Ruft das Gast-Betriebssystem hier einen kritischen Befehl auf, erzeugt der Prozessor eine Unterbrechung (Trap) und springt zum Hypervisor. Als eine weitere Erweiterung sind die Prozessoren in der Lage, beim umschalten von Gast-Modus in Root-Modus, den Status der Segment-, Kontroll- und Steuer-Register zu speichern. Wird erneut in den Gast-Modus zurückgeschaltet werden die gespeicherten Register-Zustände wiederhergestellt. Mittels der Erweiterung der Befehlssätze kann die CPU dem Hypervisor den Grund für den Aufruf des Trap nennen. Damit ist der Hypervisor in der Lage angemessen zu reagieren [4] [9]. Ein Vorteil der Erweiterung ist, dass weder das Host-Betriebssystem noch das Gast-Betriebssystem angepasst werden muss und zudem kann der Hypervisor auf aufwendige Binary Translations verzichten. Der Grund dafür liegt darin, dass alle weiteren Privilegierungsstufen beibehalten wurden. Da die CPU nun für mehrere Betriebssysteme aufteilbar ist, spricht man auch von Partitionierung der CPU. Aufgrund der Tatsache, dass nicht jede Hardware partitionierbar ist, muss der Hypervisor diese für das Gast-Betriebssystem emulieren und dabei die Zugriffe verwalten. Ein Beispiel für die nicht partitionierbare Hardware ist die Netzwerkkarte [4]. Vorteile der Virtualisierung Nach den gerade erläuterten Hauptmerkmalen der Virtualisierung sind einige Vorteile dieser Technologie bereits zu erkennen. Mittels Virtualisierung wird die Arbeitsbelastung konsolidiert, um Hardware, Energie und Raum einzusparen. Durch dieses Mittel können mehrere Betriebssysteme auf einer energiesparenden Hardware ausgeführt werden. Gerade genannte Hardware kann zuverlässiger, günstiger und effektiver sein, als eine zu der Anzahl der bereitgestellten VMs vergleichbaren Anzahl an zu beschaffene

5 5 Hardware. Weiterhin ist in großen Virtualisierungssystemen mithilfe von Live- Migration der Ausgleich von Serverauslastung möglich. Hierbei werden die VMs zur Laufzeit manuell oder automatisiert von einem Server auf einen anderen übertragen. Dadurch können Fehlertoleranzen, die auf der Arbeitsbelastung von Systemen beruhen, eingehalten werden. Weitere Vorteile sind: Vereinfachte Wartung, hohe Flexibilität, unterstützt Verfügbarkeits- und Sicherheitskonzepte und ältere bzw. veraltete Systeme und Software werden unterstützt [10]. Wie eingangs erwähnt, stehen mehrere Virtualiserungsarten zur Verfügung, diese sind unter anderem Anwendungsvirtualisierung, Paravirtualisierung, Speichervirtualisierung, Netzwerkvirtualisierung etc. Die Virtualisierungsarten, Paravirtualisierung und Vollvirtualisierung, werden in den nachfolgenden Unterkapiteln eingehend erläutert [11] [12]. 2.1 Vollvirtualisierung Das Hauptmerkmal der Vollvirtualisierung ist, dass die Gast-Betriebssysteme unverändert auf die VMs installiert werden können. In dieser Form der Virtualisierung wird die gesamte, dem Betriebssystem unterliegende, Hardware simuliert. Das Bedeutet, dass jede Software, die auf der echten Hardware ausgeführt werden kann, auch auf der simulierten Hardware in der VM ausgeführt werden kann. Dazu zählen auch mehrere Betriebssysteme, die gleichzeitig auf einer Hardware ausgeführt werden und durchaus verschieden sein können [12]. Ein Vorteil dabei ist, dass die simulierte Hardware populärer Hardware entsprechen kann und damit Treiberprobleme vermieden werden. Die Simulation wird durch Emulation von dem Hypervisor übernommen [4]. Der Hypervisor kann bei der Vollvirtualisierung vom Typ 1 oder vom Typ 2 sein. Der Typ 1 Hypervisor ist bei Vollvirtualisierung nur mit den Prozessoren möglich, die die neuen Virtualisierungs-Techniken besitzen (vgl. Kapitel 2). Der Hypervisor wird bei vielen Herstellern von Vollvirtualisierungs-Software als Virtual Machine Monitor (VMM) bezeichnet. Hier herrscht, auch in der Literatur, weitläufige Unklarheit über die genaue Bedeutung des Begriffs. Bei NOVA beispielsweise kommt sowohl eine VMM als auch ein Hypervisor vor. Im gleichen Zusammenhang findet man auch die Bezeichnungen einer hybriden VMM, die weitestgehend das Monitoring, die dynamische Verwaltung von Speicher und die Interaktion zwischen den VMs beschreibt 1 [11]. Der Übersicht halber wird der VMM aber weiterhin als Hypervisor Typ 2 bzw. Typ 1 bezeichnet. Dieser verteilt die Hardware-Ressourcen des Host-Systems an die VMs und emuliert Hardware, die nicht für den gleichzeitigen Zugriff von mehreren Betriebssystemen ausgelegt sind [9]. Beispiele für Virtualisierungslösungen, die auf dem Konzept der Vollvirtualiserung basieren, sind: VMware Server, VMware Workstation, VMware Fusion, Microsoft Virtual PC (in der Version für x86), Parallels Desktop, Parallels Workstation, VirtualBox, Kernel-based Virtual Machine (KVM), Xen-Server (ab Version 3 und entsprechender Virtualisierungstechnik in den verwendeten Prozessoren) und Mac-on- 1 Siehe dazu auch die Diskussion von Microsoft s Hyper-V Manager, Ben Armstrong:

6 6 Linux (MoL). In den nachfolgenden Unterkapiteln wird auf die Lösungen KVM und NOVA eingegangen [13]. KVM KVM steht für Kernel-based Virtual Machine und erweitert Linux um ein Subsystem, dass die Fähigkeit eines Hypervisors Typ 2 und eines Typ 1 mitbringt. Dabei werden die VMs als Prozess nahtlos in das System integriert. Wie der Name schon verkünden lässt, ist der Hypervisor als Modul in den Kernel des Betriebssystems integriert. Dabei wurde das Ziel verfolgt, ein Virtual Machine Interface (VMI) als Schnittstelle zu einem Mikrokern, sprich eine Schnittstelle mit Hypervisor-Befehlen, zu schaffen. Damit arbeitet der Linux-Kernel selbst als Hypervisor. KVM setzt dafür aber voraus, dass die verwendeten Prozessoren Virtualisierungstechnik unterstützten (vgl. Kapitel 2). Daraus folgt, dass die CPU-Virtualisierung durch die Hardware bereitgestellt wird. Bei der CPU-Virtualisierung werden Teile der Hardware direkt durch die entsprechenden Kernel angesprochen, die Verteilung erfolgt zuvor durch den Hypervisor, im Fall von KVM also durch den Kernel des Hosts. Die Ressource-Anforderungen des Gast-Betriebssystems werden im Host-Betriebssystem mit einem Emulator und gleichnamigen Prozess namens QEMU verarbeitet. Der Speicher für die VMs wird durch KVM bereitgestellt [13]. In Abbildung 3 ist die Architektur von KVM dargestellt. Als weitere Funktion bietet KVM die Fähigkeit der Live Migration, damit ist die Möglichkeit gegeben die VM im laufenden Betrieb von einem Host auf einen anderen Host zu übertragen. Dabei setzt die VM nur für einige Millisekunden aus. Für die Übertragung wird der gesamte Speicher auf den Ziel-Host übertragen, verändert sich der Speicher bzw. ein Teil des Speichers während der Übertragung, muss dieser erneut übertragen werden [10]. Abb. 3: Architektur von KVM (entnommen aus [4]) NOVA Die NOVA OS Virtualization Architecture (NOVA) wurde von der TU Dresden im Rahmen des Open Robust Infrastructure (ROBIN) Projekts entwickelt [14]. Diese Plattform sieht dem Aufbau eines Hypervisor Typ 1 Archi-

7 7 tektur sehr ähnlich, unterliegt aber einer Vollvirtualsierungs-Umgebung. Ähnlich der KVM (vgl. KVM) befindet sich der Hypervisor eingebetet in einer Mikrokernel-basierten Systemumgebung. NOVA wurde gezielte auf eine kleine Trusted Computing Base (TCB) hin entwickelt. Der entstandene Mikrokernel wurde daraufhin formal verifiziert, was darauf schließen lässt, dass es sich hier um eine sehr sichere Virtualisierungsumgebung handelt [15]. Auf die TCB wird später im Kapitel Sicherheit in KVM, NOVA und XEN eingegangen. In Abbildung 4 ist die Architektur von NOVA zu erkennen. Die hier gezeigten VMM entsprechen nur Teilweise einem Hypervisor Typ 2. Die Hauptaufgaben der multiplen VMMs ist das verwalten der Interaktion zwischen den VMs und des Speichers des Host-Systems. Weiterhin werden hier auch die sensitiven Befehle injiziert. In [11] wird explizit darauf hingewiesen, dass die Bezeichnungen der üblichen Terminologie abweichen und man nur zum Ausdruck bringen möchte, dass die VMM im nicht-privilegierten und der Hypervisor im privilegierten Modus arbeitet. Des Weiteren wurde absichtlich ein Mikrokernel-basiertes System gewählt um die Trusted Computing Base (TCB) klein zu halten. Diese Systeme verfolgen, mithilfe eines kleinen Kernels, die Principle Of Least Privilege (POLP). Damit wird versucht Sicherheit zu gewährleisten, indem die zur Verfügung stehenden Privilegien auf das unbedingt Notwendige begrenzt werden [16]. Die TCB sind Befehlssätze und Anwendungen die für das System als sicherheitskritisch gelten. Während der Entwicklung von NOVA wurde explizit darauf geachtet diese klein zu halten. Daher ist der Hypervisor auch die einzige Komponente, die im privilegierten Ring 0 bzw. Ring -1 arbeitet. Auf dem Host können auf Ring 3 Applikationen direkt unter dem Hypervisor ausgeführt werden, beispielsweise der Partition Manager oder der x86 VMM. Diese Applikationen laufen unter der Benutzerumgebung NUL (NOVA UserLand), welche sich in drei Komponenten gliedert: Den Host-Treiber, den VMs zur Verfügung gestellten Device Models und den Virtual Executer (in der VMM enthalten). Der Partition Manager verteilt statisch die Speicherbereiche, die Interrupts und die Ein- und Ausgabe-Ports des Hosts. Die Device Models werden durch den Emulator QEMU (vergleich Kapitel LiteraturKVM) eingesetzt, dessen Aufgabe es ist, den VMs, virtuelle Geräte bereitzustellen. Dabei werden für die Darstellung der Gerätezustände Register verwendet. Die nötigen Interrupts der Geräte zu den entsprechenden VMs werden durch die VMMs injiziert. Im Gegensatz zu den Lösungen XEN oder KVM ist mit NOVA augenblicklich keine Live-Migration möglich. 2.2 Paravirtualisierung Man spricht von Paravirtualisierung, wenn die Gast-Betriebssysteme auf den VMs nicht auf Ring 0 sondern auf Ring 1 ausgeführt werden. Dazu müssen proprietäre Betriebssysteme angepasst werden, um sie als Gast-Betriebssystem aufspielen zu können. Das führt auch schon zu dem Problem, dass Betriebssystemhersteller diese Anpassung verweigern können. Der Hypervisor ist vom Typ 1 und gleichzeitig auch das Betriebssystem des Hosts. Die Paravirtualisierungs- Architektur wurde für die x86-prozessor- und RISC-Architektur entwickelt und

8 8 Abb. 4: Architektur von NOVA (entnommen aus [17]) nutzt den bisher ungenutzten Ring 1 für die Gast-Betriebssysteme, womit die Host-Systeme insgesamt drei Ringe benötigen. Möchte das Gast-Betriebssystem einen privilegierten Befehl ausführen, erfolgt vom Kernel des Gast-Betriebssystems ein Aufruf an den Hypervisors. Diese sogenannten Hypercalls ruft eine Schnittstelle (API) des Hypervisors auf. Für Gast-Betriebssysteme wären damit die privilegierten Befehle abgefangen. Nun können aber bestimmte Anwendungen ebenfalls privilegierte Befehle, die sogenannten Systemcalls, an den Kernel anfordern, der sich ursprünglich in Ring 0 befand. Die Systemcalls werden vom Interrupt-Handler des Hypervisors abgefangen und von dort aus an das Gast- Betriebssystem zurückgegeben, dabei prüft der Interrupt-Handler im Hypervisor, ob der Zugriff erlaubt ist. Das Gast-Betriebssystem setzt nun einen Hypercall an die API des Hypervisors ab, dieser greift auf die entsprechende Hardware zu bzw. verarbeitet die Anfrage in Ring 0. Nur aufgrund dieser Abhandlung ist es möglich Anwendungen unverändert auf den Gast-Betriebssystemen installieren und ausführen zu können. Das Prozedere der Systemcall-Verarbeitung ist in Abbildung 5 dargestellt. Die Verwaltung der Hardware und der Interrupts übernimmt der Hypervisor, somit emuliert oder virtualisiert der Hypervisor keine Hardware, aber es können trotzdem mehrere VMs auf einen Prozessor zugreifen [12] [4]. XEN XEN wurde 2003 an der Universität zu Cambridge vorgestellt 2 und ist der derzeit einzige Open-Source-Hypervisor Typ 1 [12]. Seit Version 3 ist auch eine Vollvirtualisierungsumgebung verfügbar, somit unterstützt Xen sowohl paravirtualisierte (PV) als auch vollvirtualisierte Gast-Betriebssysteme (HVM), man spricht hier von einem Gasttyp oder Virtualization Modes. Zusätzlich werden im HVM-Betrieb auch Techniken angeboten, die ursprünglich im PV-Betrieb genutzt wurden. Zudem wird dadurch ein Paralell-Betrieb von VMs im HVMund PV-Modus möglich. VMs werden bei XEN als DomU oder Gast bezeichnet. 2 Siehe dazu XEN im Internet:

9 9 Abb. 5: Hypercall (entnommen aus [4]) Des Weiteren startet der Hypervisor von XEN eine eigene (Linux-) Instanz und lädt mit dieser Instanz die nötigen Treiber, die später über den Hypervisor verwaltet werden. Diese gerade genannte Instanz wird Dom0 bzw. Control Domain, in Anlehnung zu Ring 0, genannt. Die Speicherverwaltung nativer Betriebssysteme nutzt eine Hardware, die Memory- Management Unit (MMU), welche sich um die Adressumsetzung von virtuellen zu physikalischen Adressen kümmert. Xen führt hier eine indirekte Schicht ein, mithilfe dessen dem Gast-Betriebssystem pseudo-physikalische Adressen zur Verfügung gestellt werden. Der Hypervisor leitet Speicherzugriffe der Gast-Betriebssysteme direkt an die MMU weiter und stellt sicher, dass kein unberechtigter Zugriff erfolgt. Schreibzugriffe erfolgen per Hypercall über den Hypervisor. Beim Arbeitsspeicher gibt es die Möglichkeit harte und weiche Speichergrößen festzulegen. Die feste Größe steht dem Gast in jedem Fall zur Verfügung, während der Bereich zwischen weicher und harter Grenze dem Gast zur Verfügung stehen kann. Der Gerade beschriebene Balloon-Treiber gibt freien Arbeitsspeicher an XEN zurück, um ihn entsprechend zu verteilen. Als Gerätetreiber stellt XEN dem Gast-Betriebssystem abstrakte Geräte bereit, die die Grundfunktionen der Geräte aus der Dom0 beherrschen. Dieser Split-Device-Treiber wird im Hypervisor mittels einem I/O-Ring-Mechanismus realisiert. Ein I/O-Ring stellt eine Methode zur asynchronen Kommunikation zwischen Gästen, also virtuellen Maschinen, bereit. Ein Gast stellt eine Anfrage in den Ring, während ein anderer diese Anfrage entfernt und eine Antwort im Ring platziert. Anfragen an Geräte erfolgen entsprechend an die Dom0 [12]. 3 Isolation Ein Hypervisor besitzt drei Haupteigenschaften [13]:

10 10 Isolation: Nur der Hypervisor besitzt die Verantwortung die VMs zu kontrollieren, zu überwachen und physikalische Ressourcen zuzuweisen. Die Isolation schafft die Illusion, dass jede VM ihren eigenen Adressraum besitzt. Mit der Existenz eines Hypervisors ist jede VM von der anderen isoliert, obwohl diese auf dem gleichen physischen Host ausgeführt werden. Damit kann das Gast-Betriebssystem, auf einer VM, weder auf Anwendungen noch auf das Betriebssystem anderer VMs oder auf das Host-System zugreifen. Interposition Der Hypervisor verwaltet alle Zugriffe auf die privilegierten Befehle auf dem physischen Host. Das Gast-Betriebssystem leitet alle Interrupts und Traps an den Hypervisor weiter, dieser interagiert im Interesse des Gast- Betriebssystem direkt mit der physischen Plattform. Die I/O-Anforderungen werden vom Gast aus über virtuelle Geräte angesprochen. Die virtuellen Geräte werden vom Hypervisor über eine I/O-Abstraktionssicht an die echte Hardware weitergeleitet. Inspektion Der Hypervisor hat jederzeit Zugriff auf alle Zustände der VMs. Das beinhaltet die CPU-, Speicher- und Gerätezustände. Diese Zugriffe sind nötig aufgrund der Durchführung von Checkpointing (Snapshot), Rollback (Zurücksetzen) und Replay (Abfangen von Operationen an den Prozessor). Die Inspektion wird hauptsächlich für die Live-Migration genutzt. In diesem Kapitel wird der Hauptfokus auf die Verletzung der gerade genannten Isolations-Eigenschaft gerichtet. Doch bevor mögliche Angriffe beschrieben werden, wird das Angreifer-Modell skizziert. Der Angreifer ist nicht in der Lage in die Hardware oder dessen Firmware des Hosts einzubrechen. Damit einbezogen ist der CPU Mikrocode, der BIOS des Hosts und der Code des Hypervisors, diese Vertrauenswürdigkeit nennt man Tamper-Proof. Ebenfalls unangreifbar ist der Boot-Prozess der Host-Plattform. Der Angreifer ist in der Lage lokal oder per Fernzugriff die Software über den Hypervisor zu verändern. Weiterhin ist der Angreifer in der Lage bösartige Gast-Betriebssysteme in den VMs aufzuspielen, feindliche Gerätetreiber mit direktem Speicherzugriff zu installieren oder schädliche Hypervisor-Benutzerumgebungen zu benutzen. Schädliche Software, oder Teile einer Software, die dem Angreifer die Kontrolle des Gast-Betriebssystems ermöglichen, während der Angreifer selbst unsichtbar bleibt, wird Root-Kit genannt [11]. 3.1 Isolationskonflikte Unabhängig davon, welche Methode der Angreifer wählt ist die Isolation gefährdet, sobald der Angreifer Zugriff auf den Hypervisor besitzt oder den Betrieb andere VMs behindert. Um eine VM angreifen zu können muss zunächst festgestellt werden, ob es sich um eine VM handelt. Red Pill bietet Techniken zur Identifizierung einer VM [18]. Für die Identifizierung werden Prozesse, Registerschlüssel und Dienste in der VM untersucht. DoS Hat der Angreifer die Kontrolle einer VM gewonnen ist er in der Lage Denial of Service-Angriffe (DoS) zu tätigen. Dabei stellt er andauernd Anfragen an

11 11 die Ressourcen, wie Netzwerkkarte, Speicher, etc. und belastet die CPU. Einer Virtualisierungsumgebung mit großen Kapazitäten sollten viele Anfragen an Ressourcen nichts ausmachen, insofern dass bestimmte Server-Dienste die VM auch stark auslasten können. Problematisch wird es, wenn der Angreifer viele VMs auf einem Host unter seine Kontrolle bringt und mit diesen, die nicht-infizierten VMs, aufgrund andauernder DoS-Angriffe, behindert. Mit vielen VMs unter der Kontrolle des Angreifers, erhält dieser allmählich die Kontrolle über die betroffenen Ressourcen. Dies kann dann dazu führen, dass alle nicht-infizierten VMs keinen Zugriff auf die Ressourcen erhalten und somit zum Stillstand gezwungen werden [19]. VM Escape Der Hypervisor ist für Isolation der VMs auf dem Host verantwortlich. Der Prozess um aus der gekapselten VM auszubrechen und mit dem Hypervisor interagieren zu können wird VM Escape genannt. Ist das der Fall hat der Angreifer die Möglichkeit den Hypervisor zu korrumpieren und die Kontrolle über alle auf dem Host ausgeführten VMs bzw. den Host selbst zu erhalten. Die Angriffsfläche wird vergrößert wenn man VM-Werkzeuge, wie ein gemeinsames Clipboard (Zwischenspeicher), gemeinsame Laufwerke, etc. verwendet [19]. VM Hopping Beim VM Hopping springt der Angreifer auf eine andere VM innerhalb des Hosts. Voraussetzung für diesen Angriff ist, dass der Angreifer die IP-Adresse der anderen VM kennt. Der Angreifer kann bei einem erfolgreichem Angriff die volle Kontrolle der VM erhalten [19]. VM Monitor-Attacke Der VM Monitor wird für die Überwachung der Ressourcen des physischen Hosts, sowie die Status der einzelnen VMs verwendet. Voraussetzung dafür ist, dass der Angreifer bereits über die Kontrolle einer VM verfügt. Mit Side-Channel Attacken ist es möglich die Speicherinformationen einer weiteren VM auszulesen. Side-Channel Attacken sind besonders schwierig auszumachen, da der Angreifer durch beobachten des Systemverhaltens Schlüsse zieht bzw. Korrelationen feststellt. Aufgrund dieser Korrelationen kann der Angreifer angreifbare Situationen bzw. Momente ausnutzen, um an Informationen zu gelangen zu denen er sonst keinen Zugriff haben sollte. Eine andere Möglichkeit der Attacke wäre die Manipulation des ARP-Chaches (ARP-Poisoning) im Hypervisor, um den Datenverkehr der angegriffenen VM zum Angreifer zu leiten. Dies setzt aber ein VM Escape voraus [19]. Eine weitere resultierende Gefährdung nach erfolgreichem Angriff ist die Live Migration. Da hier schnell VMs an andere Hosts übertragen werden, kann mit der Übertragung infizierter VMs der Angreifer diese Hosts ebenfalls gefährden. [20] [21] 3.2 Sicherheit in KVM, NOVA und XEN Die Angriffsmöglichkeiten von Virtualisierungsumgebungen sind zahlreich, wie auch vielfältig. NOVA und XEN zielen in ihren Sicherheitskonzepten darauf ab,

12 12 ihre TCB (Trusted Computing Base) gering zu halten. Durch dieses Konzept verkleinert sich automatisch die Angriffsfläche des Hypervisors. Speziell NOVA wurde im Hinblick eine sehr kleine TCB bereitzustellen entwickelt. Weiterhin bietet NOVA generell eine kleinere Angriffsfläche, da viele Funktionen, wie Live Migration, nicht implementiert wurden [11]. NOVA bestätigt aber diese Funktionen als Applikation nachzurüsten. XEN hat seine Angriffsfläche dadurch verringert, dass eine Anwendungsschicht in die Dom0 eingefügt wurde, somit wurde die TCB der Linux-Instanz, also des Hypervisors Typ 1, verringert [22]. Eine weitaus effektivere Methode ist, den Angreifer nicht auf die VMs zu lassen bzw. vom Angreifer übernommene VMs zu identifizieren. KVM-SMA (KVM Security Management Architecture) wurde unter Berücksichtigung bekannter Root-Kits entwickelt und beinhaltet eine Sicherheitsüberwachung [19]. In [23] wird ebenfalls eine Sicherheitsüberwachung für XEN eingeführt. Hier wurden verschieden Sicherheits-Mechanismen eingeführt, die Hypercall-Aufrufe identifizieren und überwachen, die Netzwerkschnittstelle sichern und den Speicherbereich schützen. 4 Evaluierung Systemvirtualisierungen erzeugen für die Gast-Betriebssystem einen Overhead (Mehraufwand), der sich negativ auf die Verarbeitungsgeschwindigkeit von Programmen auswirken kann. Der Grund dafür liegt darin, dass im Gegensatz zur nativen Ausführung eines Betriebssystems, der Hypervisor eine Schicht zwischen physikalischer Plattform und Betriebssystem bildet (vergleich Kapitel Hypervisor). Für einen akkuraten Leistungsvergleich zählt auch die Größe der verwendeten Hypervisors. Hier wird die Größe über den geschriebenen Quellcode gemessen, dabei werden die Zeilen in KLOC (K für 1000 und Lines of Code) gemessen. In Abbildung 6 ist der Vergleich dargestellt. Für den Vergleich wurden noch die Mikrokernel-Version von KVM (KVM-L4), der ESXi von VMware und Microsoft s Hyper-V herangezogen, die ebenfalls Virtualisierungs-Lösungen darstellen. Der grüne Bereich der gestapelten Balkendiagramme, stellt die Größe der TCB dar. Die andersfarbigen Bereiche der Diagramme stellen die, für den Virtualiserungs-Betrieb notwendigen Komponenten dar, die außerhalb der TCB liegen. NOVA besitzt eine TCB mit einer Größe von 9 KLOC, XEN s TCB ist 100 KLOC groß und KVM hat eine TCB Größe von über 200 KLOC. Da KVM in einem Linux-Kernel integriert ist, ist Linux ebenfalls teil der TCB. KVM-L4 ist eine Portierung von KVM zum L 4 Linux, welches paravirtualisiert unter dem L4-Mikrokernel ausgeführt wird. Die kommerziellen Lösungen von Microsoft und VMware besitzen ebenfalls eine TCB, die bei Microsoft mit 100 KLOC und bei VMware mit 200 KLOC groß ausfällt. Für den Leistungsvergleich wurde die Zeit gemessen (wahre Zeit, nicht Prozess- Zeit), die für die Kompilierung des x86 Linux Kernel aufgewandt wurde. Die Kompilierung startete mit einem Cold Buffer Cache und vier parallelen Prozessen um den Effekt des Festplatten-Delays zu minimieren. Abbildung 7 zeigt den Leistungsvergleich. Als Nativ wurde ein Rechner genutzt, der ohne Virtuali-

13 13 Abb. 6: Vergleich von KLOC je Hypervisor (entnommen aus [11]) sierung mit einem Linux läuft, einen Arbeitsspeicher in der Größe von 512 MB RAM besitzt und eine intel i5 CPU verwendet. Die gerade genannte Konfiguration wurde für die VMs auf den entsprechenden Virtualisierungsumgebungen, mit der gleichen Hardware genutzt. Für die Virtualisierungsumgebungen wurde allerdings der Arbeitsspeicher auf 3 GB erhöht. Dabei wurden vom Hypervisor den entsprechenden VMs ebenfalls 512 MB RAM zugeteilt. Der Balken Direct stellt das native System mit Nutzung des Nested Paging dar. Nested Paging ist in der Befehlssatzerweiterung der neuen Prozessoren enthalten (vergleich Virtualisierungstechniken für Prozessoren) und ist eine virtualisierte Adresstabelle. Die folgenden Balken stellen die Umgebung KVM , Xen 3.4.2, VMWare ESXi 4.0 U12, und Microsoft Hyper-V Build 7100 dar. Damit liegt der Overhead mit NOVA bei ca. 1%, mit KVM bei ca. 2% und mit XEN bei ca. 2,5%. Das zeigt, dass der Overhead sehr gering ist, was nicht zuletzt den Virtualisierungstechniken der CPU zu verdanken ist. 5 Zusammenfassung In dieser Arbeit wurden die Systemvirtualisierungen XEN, KVM und NOVA dargestellt. Dabei wurden die Virtualisierungstechniken aktueller Prozessoren aufgezeigt und die Verwendung dieser Techniken in den genannten Systemvirtualisierungen dargestellt. Weiterhin wurde die Systemvirtualisierung generell charakterisiert. Mit den Isolationskonflikten wurden die Schwächen der Virtualisierung erläutert. Im Anschluss wurden Sicherheitsmechanismen genannt, die zumindest einen großen Teil dieser Schwächen mindern. Ein grober Leistungsvergleich zeigte einerseits den minimalen Overhead, der durch die Virtualisierung entsteht und andererseits den geringen Unterschied zwischen den verschiedenen Virtualisierungsumgebungen.

14 14 Abb. 7: Leistungsvergleich bei Linux-Kernel Kompilierung mit Intel Core i7 CPU (entnommen aus [11]) Zusammenfassend ergibt sich mit der Systemvirtualisierung die Möglichkeit mehrere Betriebssysteme simultan auf einem physischen Host auszuführen, aber mit der steigenden Anzahl der Möglichkeiten wächst auch die Anzahl der Sicherheitsrisiken. Der Schlüssel zu einem guten Sicherheitskonzept liegt nicht allein in einer kleinen TCB. Vielmehr muss es auch überwachende Komponenten geben, die wie ein klassischer Vieren-Scanner das System zur Laufzeit überwachen. Je mehr Gast-Betriebssysteme auf einem Hypervisor laufen, umso größer ist der Schaden den ein Angreifer an solch einem System anrichten kann. Da bereits jetzt Technologien, wie Cloud-Sevices, auf Virtualisierung nicht mehr verzichten können, steht die Sicherheit der Virtualsierungs-Technologie, sowie eine gute Sicherheits-Architektur, im Fokus von brauchbaren IT-Lösungen. Literatur 1. Xin Wan, Xinfang Zhang, Liang Chen, and Hao Jin. Tvpdc: A model for secure managing virtual infrastructure in iaas cloud. In Computational Intelligence and Security (CIS), 2012 Eighth International Conference on, pages , nov

15 2. Chao-Tung Yang, Kuan-Lung Huang, Jung-Chun Liu, Wei-Sheng Chen, and Wen- Hung Hsu. On construction of cloud iaas using kvm and open nebula for video services. In Parallel Processing Workshops (ICPPW), st International Conference on, pages , sept L. YamunaDevi, P. Aruna, D.D. Sudha, and N. Priya. Security in virtual machine live migration for kvm. In Process Automation, Control and Computing (PACC), 2011 International Conference on, pages 1 6, july Peter Mandl. Betriebssystemvirtualisierung. In Grundkurs Betriebssysteme, pages Springer Fachmedien Wiesbaden, Peter Mandl. Betriebssystemarchitekturen und betriebsarten. In Grundkurs Betriebssysteme, pages Springer Fachmedien Wiesbaden, Peter Mandl. Interruptverarbeitung. In Grundkurs Betriebssysteme, pages Springer Fachmedien Wiesbaden, Amd virtualization. (23 Jan. 2013). 8. Intel - virtualization technology. (23 Jan. 2013). 9. Avi Kivity, Yaniv Kamay, Dor Laor, Uri Lublin, and Anthony Liguori. kvm: the linux virtual machine monitor. In Proceedings of the Linux Symposium, volume 1, pages , June L. YamunaDevi, P. Aruna, D.D. Sudha, and N. Priya. Security in virtual machine live migration for kvm. In Process Automation, Control and Computing (PACC), 2011 International Conference on, pages 1 6, july Udo Steinberg and Bernhard Kauer. Nova: A microhypervisor-based secure virtualization architecture. In 5th European Conference on Computer Systems, volume 5, pages 1 14, Paul Barham, Boris Dragovic, Keir Fraser, Steven Hand, Tim Harris, Alex Ho, Rolf Neugebauery, Ian Pratt, and Andrew Warfield. Xen and the art of virtualization. In SOSP 03, Bolton Landing, New York, USA, pages 1 14, October F.A. Bazargan, Chan Yeob Yeun, and J. Zemerly. Understanding the security challenges of virtualized environments. In Internet Technology and Secured Transactions (ICITST), 2011 International Conference for, pages 67 72, dec Open robust infrastructures (robin), webpage Hendrik Tews. Formal methods in the robin project: Specification and verification of the nova microhypervisor. June Roland Schmitz, Walter Kriha, Roland Schmitz, and Walter Kriha. Sichere software: Mechanismen und konstruktionsprinzipien. In Sichere Systeme, Xpert.press, pages Springer Berlin Heidelberg, / Nul - the nova userland S.T. King and P.M. Chen. Subvirt: implementing malware with virtual machines. In Security and Privacy, 2006 IEEE Symposium on, pages 14 pp. 327, may F. Lombardi and R. Di Pietro. A security management architecture for the protection of kernel virtual machines. In Computer and Information Technology (CIT), 2010 IEEE 10th International Conference on, pages , july Bazarganand Fatma, Yeob Yeun Chan, and Zemerly Mohamed Jamal. State-of-theart of virtualization, its security threats and deployment models. In International Journal for Information Security Research, volume 2, pages , Dec Yu-Lun Huang, Borting Chen, Ming-Wei Shih, and Chien-Yu Lai. Security impacts of virtualization on a network testbed. In Software Security and Reliability (SERE), 2012 IEEE Sixth International Conference on, pages 71 77, june G. Murray Derek, Milos Grzegorz, and Hand Steven. Improving xen security through disaggregation. In SVEE 08, pages , March

16 Chunxiao Li, A. Raghunathan, and N.K. Jha. Secure virtual machine execution under an untrusted management os. In Cloud Computing (CLOUD), 2010 IEEE 3rd International Conference on, pages , july 2010.