Ausarbeitung

Isolation – Systemvirtualisierung mit Xen, KVM
und NOVA
Andreas Trenkmann
Universität Dortmund, 44227 Dortmund, Deutschland,
[email protected]
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
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 GastBetriebssystems 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
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
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
Hardware. Weiterhin ist in großen Virtualisierungssystemen mithilfe von LiveMigration 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
beschreibt1 [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-on1
Siehe dazu auch die Diskussion von Microsoft’s Hyper-V Manager, Ben Armstrong:
http://blogs.msdn.com/b/virtual_pc_guy/archive/2006/07/10/661958.aspx
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
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 ParavirtualisierungsArchitektur wurde für die x86-Prozessor- und RISC-Architektur entwickelt und
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 GastBetriebssystem 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 vorgestellt2 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: http://wiki.xen.org/wiki/Xen_Overview
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 MemoryManagement 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
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 GastBetriebssystem 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
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
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 L4 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 ProzessZeit), die für die Kompilierung des x86 Linux 2.6.32 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
Abb. 6: Vergleich von KLOC je Hypervisor (entnommen aus [11])
sierung mit einem Linux 2.6.32 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 2.6.32, 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
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 136 –141, nov.
2012.
15
2. Chao-Tung Yang, Kuan-Lung Huang, Jung-Chun Liu, Wei-Sheng Chen, and WenHung Hsu. On construction of cloud iaas using kvm and open nebula for video
services. In Parallel Processing Workshops (ICPPW), 2012 41st International Conference on, pages 212 –221, sept. 2012.
3. 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 2011.
4. Peter Mandl. Betriebssystemvirtualisierung. In Grundkurs Betriebssysteme, pages
289–309. Springer Fachmedien Wiesbaden, 2013.
5. Peter Mandl. Betriebssystemarchitekturen und betriebsarten. In Grundkurs Betriebssysteme, pages 25–48. Springer Fachmedien Wiesbaden, 2013.
6. Peter Mandl. Interruptverarbeitung. In Grundkurs Betriebssysteme, pages 49–73.
Springer Fachmedien Wiesbaden, 2013.
7. Amd virtualization. http://www.amd.com/virtualization (23 Jan. 2013).
8. Intel - virtualization technology. http://www.intel.com/virtualization (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 225–230, June 2007.
10. 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 2011.
11. Udo Steinberg and Bernhard Kauer. Nova: A microhypervisor-based secure virtualization architecture. In 5th European Conference on Computer Systems, volume 5,
pages 1–14, 2010.
12. 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 2003.
13. 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. 2011.
14. Open robust infrastructures (robin), webpage. http://robin.tudos.org, 2006.
15. Hendrik Tews. Formal methods in the robin project: Specification and verification
of the nova microhypervisor. June 2007.
16. Roland Schmitz, Walter Kriha, Roland Schmitz, and Walter Kriha. Sichere software: Mechanismen und konstruktionsprinzipien. In Sichere Systeme, Xpert.press,
pages 415–484. Springer Berlin Heidelberg, 2009. 10.1007/978-3-540-78959-8.
17. Nul - the nova userland. http://os.inf.tu-dresden.de/nul/.
18. 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 2006.
19. 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 948 –953, 29 2010-july 1 2010.
20. 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 335 – 343, Dec 2012.
21. 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 2012.
22. G. Murray Derek, Milos Grzegorz, and Hand Steven. Improving xen security
through disaggregation. In SVEE’08, pages 151 –160, March 2008.
16
23. 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 172 –179, july 2010.