Xen using VT/Pacifica extensions - FHNW - Seminar: IT-System-Management
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
FHNW
Xen using VT/Pacifica
extensions
Seminar: IT-System-Management
Betreuer: Prof. H.P.Oser
Harry Giger
25. Mai 2007
FHBB Seminar: IT-System-Management Projekt: Xen using VT/Pacifica extensions Inhalt FHNW ......................................................................................................................... 1 XEN USING VT/PACIFICA......................................................................................... 1 EXTENSIONS............................................................................................................. 1 1. VIRTUELLE MASCHINEN ................................................................................... 1 2. DER NUTZEN VON VIRTUELLEN MASCHINEN ................................................ 1 3. VIRTUALISIERUNG AUS DER ZEIT ‚PRÄ-HARDWARE-UNTERSTÜTZUNG‘ . 3 4. XEN ...................................................................................................................... 5 4.1 Die Funktionsweise von Xen ................................................................................................................. 5 4.2 Das Ringmodell des x86 Prozessors ..................................................................................................... 6 4.3 Die Xen-Architektur.............................................................................................................................. 8 5. VIRTUALISIERUNG AUS DER ZEIT ‚POST-HARDWARE-UNTERSTÜTZUNG‘ . ............................................................................................................................ 10 5.1 Intel und AMD go for virtualization.................................................................................................. 10 6. INSTALLATION VON XEN 3.0 AUF OPENSUSE 10.2 ..................................... 13 6.1 Installation eines Gastsystems ............................................................................................................ 14 7. FAZIT.................................................................................................................. 24 8. QUELLEN........................................................................................................... 25 Harry Giger
FHNW Seminar: IT-System-Management
Projekt: Xen using VT/Pacifica extensions
1. Virtuelle Maschinen
Unter einer Virtuellen Maschine versteht man eine Software, die zwischen der Hardware eines Com-
1
puters und dessen Betriebssystem eine ‚virtualisierte‘ Umgebung erzeugt.
Virtuelle Maschinen werden verwendet, um auf einem Computer, neben dem Basis-Betriebssystem
(Host), mehrere (verschiedene) Betriebssysteme laufen zu lassen. In diesem Zusammenhang spricht
man auch des öfteren von Virtualisierung.
Ermöglicht wird diese Art des „Betreibens von mehreren Maschinen auf einem Computer“ durch eine
spezielle Software bzw. Software-Schicht, die auf dem Hostsystem läuft. Diese Schicht wird üblicher-
weise Virtual Machine Monitor (VMM) oder Hypervisor genannt.
2. Der Nutzen von virtuellen Maschinen
Entgegen der landläufigen Meinung, dass virtuelle Maschinen (bzw. die Technik der ‚Virtualisie-
2
rung‘ ) erst mit dem Produkt ‚VMware‘ erfunden wurde, ist es in Wirklichkeit so, dass schon in den
Anfängen des Computerzeitalters (in den 60iger Jahren) an der Virtualisierung gearbeitet wurde.
Das Ziel war eine virtuelle Maschine als Kombination von Hardware und Software zu entwickeln.
Die Bezeichnung ‚Virtuelle Maschine‘ für die ‚Virtualisierung‘ kommt vom IBM M44/44X experimental
paging system.
Der Zweck dieser Maschine war zum einen die Entwicklung von Paging, zum anderen das Erarbeiten
eines Konzepts für virtuelle Maschinen und Performance Messungen. Auf deutsch gesagt, diese Ma-
3
schine diente reinen Forschungszwecken.
Somit ging es damals (wie noch heute) um zwei zentrale Themen:
1. Wie kann ein System geschaffen werden, dass im weitesten Sinne unabhängig von der darunter-
liegenden Hardware ist.
2. Wie kann diese Hardware möglichst gut ausgenützt werden.
Gerade im Umfeld von Firmen-Netzwerken und Data-Centern ist das Verlangen nach Performance,
gepaart mit hoher Ausfallsicherheit, Erweiterbarkeit und der Möglichkeit der bequemen Administration
enorm wichtig. Mit der Virtualisierung als Basis-Technologie wird ein grosser Schritt in diese Richtung
gemacht.
Somit kann bezüglich der Virtualisierung die folgende Aussage getroffen werden:
Das Ziel der Virtualisierung liegt im effizienten und sicheren Betrieb von Anwendungen sowie dem
kontrollierten Management der bereitzustellenden Ressourcen angesichts der stetig wachsenden
Komplexität von Rechnern, Netzen und Speichersystemen.
Im Folgenden soll der Nutzen der Virtualisierung, d.h. der Nutzen des Gebrauchs von virtuellen Ma-
schinen, näher betrachtet werden.
1
Quelle: http://en.wikipedia.org/wiki/Virtual_machine
2
Genaueres über die ‘Virtualisierung’ folgt weiter hinten in diesem Dokument.
3
Quelle: http://en.wikipedia.org/wiki/IBM_M44/44X
Harry Giger 1
FHNW Seminar: IT-System-Management
Projekt: Xen using VT/Pacifica extensions
Serverkonsolidierung
Studien belegen, dass Server im Schnitt nur zu 8 bis 30% mit der ihnen zugedachten Arbeit ausgela-
stet sind, den Rest der Zeit nutzen sie um unnötig Strom zu verbrauchen.
Der Einsatz mehrerer virtueller Maschinen auf einem Rechner ermöglicht eine wesentlich bessere
Auslastung der Hardware (bis zu 70 bis 80%). Ein weiterer positiver Effekt ist die Entkopplung der
Systeme voneinander. D.h. die virtuellen Systeme kommen einander nicht in die Quere, sie sind voll-
kommen voneinander abgeschottet. Somit werden die Tragweiten von Systemabstürzen gemindert.
Flexibilität im Betrieb von Applikationen
Dies ist ein zentraler Aspekt der Nutzung von Servervirtualisierung. Aus der Erhöhung der Flexibilität
im Umgang mit Servern ergeben sich die folgenden Vorteile:
- Schnellere Reaktion bei Veränderungen in der Server (Netzwerk)- Struktur, kürzere Bereitstel-
lungszeiten.
- Vereinfachung der Administration, Rollout beschleunigen (durch Klonen, Kopieren etc.). Dadurch
erfolgt eine Reduzierung der Administrationskosten.
- Betrieb von Legacy-Applikationen, d.h. es kann zum Beispiel parallel ein Windows 3.11 System in
Betrieb genommen werden.
- Quality of Service (QoS) wird gesteigert.
- Passgenaue (Betriebssystem-) Umgebungen können definiert werden.
Steigerung der Verfügbarkeit
Stichwort RAS (Reliability, Availability, Service-ability).
Hier kommt die Mobilität von virtuellen Maschinen voll zum Tragen. Da eine virtuelle Maschine auf der
Festplatte in Form einer Datei bzw. Verzeichnis vorliegt, sind Verschieben, Kopieren etc. problemlos
möglich. Backups, Disaster Recovery, Failover, alle diese Aktionen werden erheblich vereinfacht.
Ebenfalls wird die Skalierung eines Systems, d.h. das Einbringen neuer Hardware, ohne eine Neuin-
stallation des Betriebssystems möglich.
Flexible Plattform für Testing und Staging
An Entwicklungsplattformen werden verschiedene Anforderungen gestellt:
- ‚On demand‘-Verfügbarkeit und schnelle einfache Bereitstellung
- Sichere Abschottung von anderen Systemen
- Versioning verschiedenster Komplett-Umgebungen
- Virtuelle Bereitstellung von Hardwarekomponenten aus Zeit- bzw. Kostengründen.
Virtualisierungslösungen bieten für Test und Entwicklung bereits seit Jahren eine erprobte und äu-
sserst flexible Umgebung und sind deshalb vermutlich derjenige Bereich, der bislang am intensivsten
die vorhanden Produkte nutzte.
All diese Nutzen zusammengefasst ergeben auch Konsequenzen auf das IT-Personal, dass den Um-
gang mit den virtuellen Maschinen pflegt.
- Das IT-Personal kann durch die Zeitersparnis für andere Projekte eingesetzt werden.
- Reaktions- und Bereitstellungszeit verkürzen sich.
- Die System-Verfügbarkeit wird deutlich verbessert
4
- Die IT-Abteilung kann höhere Qualität liefern, da sie mehr Zeit für „wirklich“ wichtige Dinge hat .
4
Zumindest in der Theorie!
Harry Giger 2
FHNW Seminar: IT-System-Management
Projekt: Xen using VT/Pacifica extensions
3. Virtualisierung aus der Zeit ‚Prä-Hardware-Unterstützung‘
Zunächst noch eine kleine Begriffserklärung. Und zwar geht es um die zwei Begriffe Hostsystem und
Gastsystem. Ein physischer Computer, der ein zweites Betriebssystem in einer virtuellen Maschine
beherbergt, nennen wir das Hostsystem. Das Betriebssystem, das in der virtuellen Maschine läuft,
wird Gastsystem genannt.
In den heutigen virtuellen Maschinen kommen grundsätzlich zwei verschiedene Technologien zur
Anwendung:
Full Virtualization
Auch „Virtualisierung auf Betriebssystem-Ebene“ genannt.
Hier ist das Gastsystem vollkommen abgeschottet von der Hardware des Hostsystems. Das bedeutet,
dass weder in den Applikationen des Gastsystems, noch im Gastsystem selber Modifikationen nötig
sind. Das Gastsystem ist sich nicht bewusst, dass es in einer virtuellen Maschine läuft, es erscheint
ihm, als liefe es auf einem gewöhnlichen physischen System. Hinzu kommt, dass das Gastsystem
eine originalgetreue ‚virtuelle‘ Hardware vorfindet, angefangen bei dem I/O System, bis hin zum BIOS.
Die Schnittstelle zwischen dem Gastsystem und dem Hostsystem bildet eine Softwareschicht, die
‚Virtual Machine Monitor‘ oder kurz VMM genannt wird. Der Virtual Machine Monitor fungiert dabei
als eine Art Übersetzer zwischen dem Betriebssystem des Host’s und dem Gastsystem. Er übersetzt
Software-Interrupts (Traps) des Gastsystems direkt in System Aufrufe (system calls).
Abb. 1: Full Virtualization Architektur
Bei dieser Technologie kommen vor allem die im vorherigen Abschnitt erwähnten Vorteile der Sicher-
heits- und Systemkritischen Anwendungen zum tragen. Ein weiterer Vorteil ist die einfache Installation
des Gastsystems.
Ein Nachteil jedoch ist, dass durch diese totale Virtualisierung, also eben diese Übersetzer-Funktion
des VMM‘s, die Performance innerhalb des Gastsystems verschlechtert wird.
Harry Giger 3
FHNW Seminar: IT-System-Management
Projekt: Xen using VT/Pacifica extensions
Die älteren Produkte von VMware sowie der ‚Microsoft Virtual PC/Server‘ sind typische Vertreter die-
ser Technologie.
Paravirtualization
Auch „Virtualisierung auf Hardware-Ebene“ genannt.
Im Gastsystem läuft keine virtuelle Hardware mehr. Auch die Übersetzung von Sofware-Interrupts in
system calls entfällt. Es wird, anstelle des ‚Virtual Machine Monitors‘ bei der Full Virtualization, der so
genannte Hypervisor für den direkten Zugriff auf die zugrundeliegende Hardware verwendet.
Dieser Ansatz verbirgt die Virtualisierung nicht vor dem Gast, sondern das virtualisierte System
„weiss“, dass es virtualisiert läuft. Dazu wird sogenannter virtualization-aware Programmcode (API) in
das Betriebssystem des Gastes integriert.
Das bedeutet, dass das Gastsystem entsprechend angepasst werden muss.
Der Vorteil dieser Technologie ist die hohe Performance des Gastsystems. Diese liegt fast bei der
Performance des Hostsystems.
Der grösste Nachteil (bis anhin) ist, dass das Gastsystem angepasst werden muss, was die Installati-
on komplizierter macht und die Auswahl der Gastsysteme einschränkt.
Abb. 2: Paravirtualization Architektur
Selbstverständlich können mehrere unterschiedliche Gastsysteme gleichzeitig laufen.
Harry Giger 4
FHNW Seminar: IT-System-Management
Projekt: Xen using VT/Pacifica extensions
4. Xen
Mehrere wichtige Designziele steuerten und steuern die Entwicklung von Xen:
- Kompromisslose Open Source-Ausrichtung der Software
- Unterstützung einer möglichst grossen Anzahl von Gastsystemen (inkl. Windows)
- Keine Änderungen der Applikationen der Gastseite
- Optimale Performance der Gastsysteme
- Volle Unterstützung der gängigen Hardwareplattformen
- Äusserste Stabilität und Sicherheit (inkl. einer möglichst schlanken Implementation)
4.1 Die Funktionsweise von Xen5
Xen war ursprünglich ein Projekt der University of Cambridge, das zum ersten Mal 2003 der Öffent-
lichkeit vorgestellt wurde.
Bei der von Xen genutzten Technik handelt es sich um so genannte Paravirtualisierung. Dabei wird
ein zusätzliches Betriebssystem virtuell neu gestartet. Hierfür wird jedoch keine Hardware emuliert,
sondern die virtuelle Maschine greift über eine Softwareschnittstelle, Hypervisor genannt, auf die
gemeinsam genutzten Ressourcen des Host-Systems wie CPU, Arbeitsspeicher, Festplatten oder
Netzwerkkarten zu.
Der Hypervisor sorgt gleichzeitig dafür, dass die verschiedenen Betriebssysteme vollständig vonein-
ander isoliert bleiben. Jedes Gastsystem läuft in seiner eigenen Domäne (DomainU), die unterste
Domäne (Domain0) belegt Xen, also das Hostsystem selbst.
Die Softwareschnittstelle ähnelt der darunter liegenden physischen Hardware, ist aber nicht mit ihr
identisch.
Xen unterstützt zwei Arten von Kernel, der eine ist derjenige, ab dem das Hostsystem gebootet wird,
der sogenannte xen0-Kernel. Dieser wird bei der Installation von Xen im Verzeichnis /boot abgelegt.
Auf diesem Kernel läuft auch die Xen-Domäne (Domain0) bzw. der Hypervisor selbst. Ebenfalls bein-
haltet der xen0-Kernel auch die ganzen Treiber für die Hardware des Systems.
Die zweite Kernel-Art, sind die Kernel der Gastsysteme (DomainU). Sie greifen für gewöhnlich über
6
die Treiber des xen0-Kernels auf die Hardware zu .
Anders ausgedrückt könnte man sagen, dass sich mehrere Betriebssysteme die Hardware des Com-
puters, unter Aufsicht des Xen-Hypervisors, teilen.
Dieser Ansatz wird, wie oben dargestellt, als Paravirtualisierung bezeichnet.
Das grösste Problem der Paravirtualisierung ist, dass das Gast-Betriebssystem bis anhin speziell an-
gepasst werden musste, um auf dem Wirtssystem als virtuelles OS laufen zu können.
Der Lohn für diese Mühe ist eine deutlich bessere Performance als bei Virtualisierungslösungen, die
die gesamte Hardware emulieren (siehe Full Virtualization).
Xen verfügt über einen sehr schlank gehaltenen Hypervisor, der die Zugriffe der virtuellen Maschinen
auf die Hardware des Hostsystems steuert und somit zusätzlich die Performance verbessert.
5
Quelle: http://www.computerwoche.de/produkte_technik/software/587715/index2.html
6
Allerdings ist es nicht unbedingt nötig, dass die Gastsysteme ihre eigenen xen-Kernel besitzen. Es ist möglich,
und durchaus auch üblich, dass die Gastsysteme den xen0-Kernel des Hostsystems als ihren Kernel verwenden.
Harry Giger 5
FHNW Seminar: IT-System-Management
Projekt: Xen using VT/Pacifica extensions
4.2 Das Ringmodell des x86 Prozessors7
Mit der Veröffentlichung des 286er Intel Prozessors 1982 wurde u.a. die Technologie der ‚Priority
Levels‘ (Prioritätsebenen) eingeführt. Programme, die auf einem solchen System laufen, können in
den verschiedenen Levels ausgeführt werden. Es gibt insgesamt vier Level, diese werden im Nor-
malfall als Ringe dargestellt.
Abb. 3: Prioritätsebenen eines x86-Prozessors
Im Ring 0 können alle Befehle des Prozessors ausgeführt werden. Je grösser die Ringnummer wird,
desto eingeschränkter wird die Ausführung von Befehlen. Der Ring 3 ist also der restriktivste Ring.
Es ist den Ringen möglich mittels sogenannter Gates (Tore) miteinander zu kommunizieren. Somit ist
es einem höhergelegenem Ring möglich die Ergebnisse privilegierter Operationen von einem darun-
terliegenden Ring anzufordern. Sollten die Privilegien des darunterliegenden Ringes unzureichend
sein, so kann dieser die Anfrage wiederum an einen darunterliegenden Ring weiterleiten. Dem jeweils
privilegierterem Ring obliegt hierbei die Aufgabe die Anfragen zu validieren und autorisieren.
Ist das mit positivem Ergebnis geschehen, so führt dieser die Befehle und liefert anschließend das
Ergebnis der Operation zurück.
Währenddem es theoretisch also möglich ist vier Ringe auf x86-kompatibler Hardware zu nutzen,
verwenden die meisten Betriebssysteme lediglich zwei davon, diese werden ‚kernel mode‘ und ‚user
8
mode‘ genannt. Dabei entspricht der ‚kernel mode‘ dem Ring 0 und der ‚user mode‘ dem Ring 3.
Xen modifiziert das Ganze nun so, dass Xen selbst, also der Xen-Hypervisor im Ring 0 (Supervisor
Mode) läuft. Die Gast-Betriebsysteme werden in den Ring 1 verschoben und können damit keine
privilegierten Instruktionen mehr ausführen. Versuchen sie es trotzdem, löst der Prozessor eine Ex-
ception (interner Fehlerstatus) aus, die dann vom Hypervisor behandelt werden kann, z.B. durch Be-
enden des Gastes.
Durch die Massnahme, dass der Xen-Hypervisor (bzw. der Xen0-Kernel) im Ring 0 läuft, erhält er vom
System die höhere Priorität, als die Gastsysteme, die im Ring 1 laufen.
7
Quelle: http://www.nodemaster.de/xen-grundlagen/
8
Auch ‘supervisor mode’ genannt.
Harry Giger 6FHNW Seminar: IT-System-Management
Projekt: Xen using VT/Pacifica extensions
Die Applikationen des Gastes laufen nach wie vor im ‚user mode‘ auf Ring 3, müssen daher also nicht
modifiziert werden.
Abb. 4: Die Xen-Ring Struktur
Aus Sicht der Memory Management Unit (MMU), die nur die beiden Privilegstufen user mode und
kernel mode kennt, laufen der Gast im Ring 1 und der Hypervisor im Ring 0 beide mit System-
Priviliegien.
Damit besteht die Gefahr, dass der Gast Speicherbereiche des Hypervisors überschreibt. Um sich
davor zu schützen, verwendet Xen Segmente und setzt deren Limits so, dass der Gast nicht in den
Bereich von Xen hineinkommt.
Die Modifikation der x86-Ringstruktur sowie der Einsatz des Hypervisors haben zur Folge, dass die
Performance eines Gastsystems, das in Xen läuft, der Performance des Hostsystems sehr nahe
kommt.
Der Bootvorgang eines Xen-Systems läuft nun folgendermassen ab:
1. Der Bootloader (Grub) lädt den Xen-Hypervisor
2. Anschliessend lädt dieser den Domain0-Kernel (Linux)
3. Gegebenenfalls wird danach noch die initrd der Domain0 geladen.
Die Datei /boot/grub/menu.lst hat demnach das folgende Aussehen:
title Xen
root (hd0,0)
kernel /boot/xen.gz
module /boot/vmlinuz-2.6-xen root=/dev/hda1
module /boot/initrd-xen
Harry Giger 7FHNW Seminar: IT-System-Management
Projekt: Xen using VT/Pacifica extensions
4.3 Die Xen-Architektur
Auf der Grundlage der im vorherigen Abschnitt erläuterten Priority-Levels, hat die Architektur von Xen
9
das folgende Aussehen :
Abb. 5: Die Xen Architektur
Die privilegierte Xen-Domain (Domain0) übernimmt mit Hilfe des Hypervisors die I/O Operationen für
die Gast-Domains (DomainU).
D.h. alle Hardware-Aufrufe der Gastsysteme werden über den Xen0-Kernel, also die Domain0 abge-
handelt. Ebenfalls ist es so, dass das Gastsystem nur die Hardware kennt, die ihr von seiten der Do-
main0 zur Verfügung gestellt wird. In der Terminologie von Xen wird das „Exportieren“ von Devices an
die DomainU genannt.
Die jeweils über die Hardwaregeräte verfügende Domain wird auch als ‚Driver Domain‘ bezeichnet, da
sie die Gerätetreiber besitzt und exportiert. Diese Unterscheidung leitet sich von der Fähigkeit von
Xen ab, einzelne Hardwarekomponenten oder Geräte (devices) an einzelne Gastsysteme (DomainUs)
exklusiv zu übergeben. Somit kann eine beliebige unprivilegierte Domäne zu einer ‚Driver Domain‘
werden.
Schematisch gesehen, sieht das dann so aus:
9
Quelle: http://eclipt.uni-klu.ac.at/ecliptwiki/LinuxDay2007/Virtualisierung/060_Xen
Harry Giger 8FHNW Seminar: IT-System-Management
Projekt: Xen using VT/Pacifica extensions
Abb. 6: Hardware Aufrufe in Xen (inkl. Gast als ‚Driver Domain‘)
Die folgende Darstellung zeigt die Aufrufe der Treiber via Domain0 detaillierter und zwar gemäss dem
Prinzip der so genannten ‚Split Drivers‘:
Abb. 7: Hardware Aufrufe detailliert
Aus dieser Darstellung wird ersichtlich, wie die Gastsysteme Hardware-Aufrufe via Domain0 tätigen.
Dies geschieht über zwei Layer, darum die Bezeichnung ‚Split Drivers‘. Der eine Layer ist auf Doma-
in0, also auf der Hostsystem-Seite, dieser wird Backend-Layer genannt. Der andere Layer liegt auf
DomainU Seite, also auf der Seite der Gastsysteme und wird Frontend-Layer genannt. Unterteilt wer-
den die Layers zusätzlich in Aufrufe für Block-Devices und Network-Devices.
Harry Giger 9FHNW Seminar: IT-System-Management Projekt: Xen using VT/Pacifica extensions Die Kommunikation der Layers, d.h. die Kommunikation vom Gastsystem mit dem Hostsystem, erfolgt über das ‚Shared Memory‘ sowie einem so genannten ‚InterDomain Event Channel‘. Über diesen ‚InterDomain Event Channel‘ werden Nachrichten und Status-Meldungen ausgetauscht, z.B. „Lesen von Block-Device beendet“ o.ä. Über das ‚Shared Memory‘ werden dann die Anforderun- gen der Daten sowie deren Austausch selbst vorgenommen. 5. Virtualisierung aus der Zeit ‚Post-Hardware-Unterstützung‘ Bis jetzt war in diesem Dokument, abgesehen von ein paar Hinweisen, immer davon die Rede, das bei der Paravirtualisation das Gastsystem anpasst werden muss, um in der virtuellen Maschine lauffä- hig zu sein. Dies war auch bis anhin der Grund, warum ein Windows-Betriebssystem nicht in Xen in- stalliert werden konnte. Ausserdem war bis zur Xen Version 3.0 die Installation von Windows als Gastsystem gar nicht vorge- sehen und demzufolge auch nicht möglich. Doch dies soll sich jetzt ändern. Mit der Version 3.0 von Xen wurde softwaremässig die Möglichkeit geschaffen, das Betriebssystem Windows als Gastsystem einzurichten. Doch das allein reicht nicht, auch bei der Hardware waren entsprechende Modifikationen nötig. Durch die Integration eines, die Virtualisierung unterstützenden Befehlssatzes in die neuste Prozessoren-Generation von Intel (namens Vanderpool) und AMD (na- mens Pacifica), entfällt dann auch entgültig die Modifikation der Gastsysteme. Doch wie funktionieren nun die neusten Prozessoren, was ist der Grund, dass die Gastsysteme nicht mehr modifiziert werden müssen? 5.1 Intel und AMD go for virtualization Sowohl Intel als auch AMD haben unabhängig von einander Prozessoren entwickelt, die die Virtuali- sierung in ihren Befehlssätzen unterstützen. Diese Befehlssätze machen es möglich, dass der Hyper- visor einer virtuellen Maschine ein Gastsystem ausführen kann, ohne dass dieses modifiziert wurde. Zunächst aber noch kurz die Definition des Begriffs Virtualisierung: „Virtualization is the pooling and abstraction of resources in a way that masks the physical nature and boundaries of those resources from the resource users.“ Oder ein bisschen einfacher im Laienjargon: Virtualisierung ist ein Oberbegriff für die Technik, die es einem erlaubt, virtuelle Maschinen innerhalb eines anderen Systems laufen zu lassen. Bei Intel heisst diese Technologie IVT für ‚Intel Virtualization Technology‘ (wird auch manchmal mit dem Codenamen Vanderpool bezeichnet). Da Intel von Anfang an in das Xen-Projekt integriert war, wurde Xen schon mit dem nötigen Code ausgerüstet, mit dem die neuen Vanderpool-Prozessoren angesprochen werden können. Bei AMD wird diese Technologie AMD-V (V für Virtualization) genannt. Auch hier hört man oft den AMD internen Codenamen Pacifica, welcher für das Projekt steht. Die wichtigste Struktur im Code der Xen-Implementation bezüglich der VT-Technologie von Intel ist die so genannte VMCS-Struktur (vmcs_struct), oder kurz VMCS (Virtual Machine Control Structure) genannt. Harry Giger 10
FHNW Seminar: IT-System-Management
Projekt: Xen using VT/Pacifica extensions
Was nun den Intel-Prozessor betrifft, so wurde dessen Befehlssatz um die folgenden 10 ‚OpCodes‘
(VMX-Befehle) erweitert:
1. VMCALL: (VMCALL_OPCODE in vmx.h)
→ Ruft den Virtual Machine Monitor (Hypervisor) auf.
2. VMCLEAR: (VMCLEAR_OPCODE in vmx.h)
→ Kopiert die VMCS Daten in das Memory.
3. VMLAUNCH: (VMLAUNCH_OPCODE in vmx.h)
→ Startet eine virtuelle Maschine und ändert den Status von VMCS.
4. VMPTRLD: (VMPTRLD_OPCODE in vmx.h)
→ Setzt einen Zeiger auf VMCS. Wrapper: _vmptrld (u64 addr) in vmx.h.
5. VMPTRST: (VMPTRST_OPCODE in vmx.h)
→ Speichert einen Zeiger auf VMCS. Wrapper: _vmptrst (u64 addr) in vmx.h.
6. VMREAD: (VMREAD_OPCODE in vmx.h)
→ Liest ein bestimmtes Feld in VMCS.
Wrapper: _vmread(x, ptr) in vmx.h.
7. VMRESUME: (VMRESUME_OPCODE in vmx.h)
→ Lässt die virtuelle Maschine ihre Arbeit wieder weiterführen.
8. VMWRITE: (VMWRITE_OPCODE in vmx.h)
→ Schreibt ein bestimmtes Feld in VMCS. Wrapper: _vmwrite (field, value).
9. VMXOFF: (VMXOFF_OPCODE in vmx.h)
→ Beendet eine VMX Operation. Wrapper: _vmxoff (void) in vmx.h.
10. VMXON: (VMXON_OPCODE in vmx.h)
→ Startet eine VMX Operation. Wrapper: _vmxon (u64 addr) in vmx.h.
Diese 10 neuen Befehle sind das, was ,Intel Virtualization Technology‘ ausmacht. Durch sie wird eine
neue Ebene erzeugt, die speziell dem Hypervisor vorbehalten ist, nämlich: VMX Root.
Intel-Prozessoren die mit dieser Technologie arbeiten, kennen die drei standardmässigen x86-Ringe
(siehe Abbildung 3) für den so genannten VMX-Nonroot Bereich, in dem die Gäste (DomainU) laufen.
Unter diesen Nonroot-Bereich wird nun eine neue Ebene geschoben, die VMX-Root genannt wird.
Diese neue Ebene besteht aus der altbekannten Dom0, also dem Hypervisor. Analog der Zeit ,Prä-
Hardware-Unterstützung, besitzt auch hier der Hypervisor die Kontrolle über sämtliche Hardware (in-
klusive dem Prozessor) des Systems.
Was die Privilegien-Level betrifft, so bleiben diese unverändert, das Gastsystem wird also nicht, wie
bei der Paravirtualisation, in den Privilegien-Ring 1 verschoben.
Der Hypervisor kann nun den Prozessor durch ‚VM Entries‘ genannte Sequenzen veranlassen, im
VMX-NonRoot Modus, d.h. in den Gästen, zu arbeiten. Der Übergang zurück in den VMX-Root Modus
Harry Giger 11FHNW Seminar: IT-System-Management
Projekt: Xen using VT/Pacifica extensions
erfolgt durch die VM Exit Befehle. Das Verhalten einer Maschine im VMX-Root Modus ist übrigens
ähnlich dem einer ‚normalen‘ Maschine ohne VT-Technologie.
Die Kontrolle über die VM-Übergänge übernimmt die VMCS-Datenstruktur. Diese Datenstruktur ist
sowohl für die Übergänge in und aus den Non-Root-Modi, als auch für den Prozessor im Gastsystem
selbst verantwortlich.
Über die VMX-Befehle: VMCLEAR, VMPTRLD, VMREAD und VMWRITE lässt sich das VMCS ein-
stellen (siehe auch die Auflistung der VMX-Befehle weiter oben).
Diese Architektur schafft neue Kontrollstrukturen, um dafür zu sorgen, dass sich der Gast und der
Hypervisor nicht in die Quere kommen und dass für die Gäste jeweils separate Adressräume ge-
10
schaffen werden können.
Die folgende Abbildung zeigt die Aufteilung des Systems in den Root- und den Nonroot-Bereich:
Abb. 8: VMX-Root und VMX-NonRoot Bereiche bei VT-Prozessoren
Die Architekturen von Intels IVT als auch von AMDs Pacifica sind sich sehr ähnlich. Allerdings muss
das in einem gewissen Grad so sein, da der Xen-Code für beide Architekturen geschrieben ist.
In Verbindung mit diesen neuen Befehlssätzen in den Prozessoren ist es mit Xen nun möglich, sowohl
paravirtualisierte (z.B. Linux-Systeme) als auch vollvirtualisierte Gastsysteme (z.B. Windows-Systeme)
laufen zu lassen.
Mit dieser neuen Prozessor-Technologie wird sozusagen das Beste aus beiden Welten heraus gekit-
zelt. Zum einen den vollen Zugriff des Gastes auf die Hardware der Maschine, zum anderen die Frei-
heit den Gast nicht verändern zu müssen, wie man das von VMware her kennt.
10
Quelle: http://www.tecchannel.de/technologie/prozessoren/402566/index4.html
Harry Giger 12FHNW Seminar: IT-System-Management
Projekt: Xen using VT/Pacifica extensions
6. Installation von Xen 3.0 auf openSuSE 10.2
Das installierte Hostsystem läuft auf einem Intel(R) Core(TM)2 CPU 6300 Prozessor mit 1.86GHz.
Die Xen-Umgebung auf dem Hostsystem folgendermassen einrichten:
1. Via graphischer Benutzeroberfläche das YaST2-Kontrollzentrum starten und in der Abteilung
Software ‚Software installieren oder löschen‘ anwählen.
2. Unter ‚Suche:‘ das Stichwort xen eingeben, anschliessend die folgenden Pakete zur Installation
auswählen:
kernel-xen
xen
xen-libs
xen-tools
xen-tools-ioemu
Ebenfalls installiert - zwecks Erleichterung der ganzen Sache - sollte der ‚Virtual Machine Mana-
ger‘ werden. Dies ist das Paket:
yast2-vm
3. Nach der Installation wiederum im YaST2-Kontrollzentrum in der Abteilung System ‚Verwaltung
11
von virtuellen Computern (Xen) ‘ wählen.
Man wird dann gefragt, ob man die ganze Konfiguration für virtuelle Maschinen auf dem System
erstellen will. Dies wird natürlich mit einem ‚Ok‘ bestätigt.
Es werden daraufhin im File /boot/grup/menu.lst die folgenden Einträge angehängt:
title Kernel-2.6.18.2-34-xen
root(0,4)
kernel /xen.gz dom0_mem=256M
module /vmlinuz-2.6.18.2-34-xen root=/dev/hda6 vga=0x317 resume=/dev/hda8\
splash=silent showopts
module /initrd-2.6.18.2-34-xen
Wichtig!
Um das korrekte Funktionieren des Xen-Systems zu garantieren, muss zusätzlich noch die Grö-
sse des RAM-Speichers für das Hostsystem (rot) zusätzlich eingetragen werden.
4. Wenn der ‚Virtual Machine Manager‘ das Einrichten beendet hat, muss das System über den neu-
en Xen-Kernel frisch gebootet werden.
11
Dieses Tool entspricht dem vorher installierten ‘Virtual Machine Manager’.
Harry Giger 13FHNW Seminar: IT-System-Management
Projekt: Xen using VT/Pacifica extensions
6.1 Installation eines Gastsystems
Dass ein unverändertes Gastsystem in einer virtuellen Xen-Maschine funktionieren kann, muss si-
chergestellt werden, dass die Virtualisierungsfunktion des Prozessors aktiviert (enabled) ist. Dies kann
im BIOS nachgeschaut und entsprechend verändert werden.
Auf einem laufenden Suse-System kann diese Funktionalität mit dem folgenden Befehl überprüft wer-
den:
# cat /proc/cpuinfo
12
Im Abschnitt flags sollte dann der Eintrag vmx (rot) erscheinen :
processor :0
vendor_id : GenuineIntel
cpu family :6
model : 15
model name : Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz
stepping :2
cpu MHz : 1866.696
cache size : 2048 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36 clflush dts acpi mmx fxsr
sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm
bogomips : 4668.26
processor :1
vendor_id : GenuineIntel
cpu family :6
model : 15
model name : Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz
stepping :2
cpu MHz : 1866.696
cache size : 2048 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
12
Bei einem AMD-Prozessor sollte anstelle von vmx svm stehen.
Harry Giger 14FHNW Seminar: IT-System-Management Projekt: Xen using VT/Pacifica extensions fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc up pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm bogomips : 4668.26 Ebenfalls ersichtlich wird der Typ der CPU inkl. deren Cache-Speicher (blau). Mit dem folgenden Kommando kann überprüft werden, ob die Hardware-Konfiguration stimmt und ob Xen die Hardware als VT-/SVM tauglich erkennt: # xm dmsg | grep VMX Die Antwort für Intel-Maschinen sollte so aussehen: (XEN) VMXON is done Die Antwort für AMD-Maschinen so: (XEN) AMD SVM Extensions is enabled for cpu 0 (XEN) AMD SVM Extensions is enabled for cpu 1 Haben diese Prüfungen alle in einem positiven Resultat geendet, so steht der Installation des Gastsy- stems nichts mehr im Wege (zumindest was die Anforderungen an die Hardware betrifft). Harry Giger 15
FHNW Seminar: IT-System-Management
Projekt: Xen using VT/Pacifica extensions
Der ‚Virtual Machine Manager‘ (YaST2)
Für das Installieren des Gastsystems soll der von Suse mitgelieferte ‚Virtual Machine Manager‘ ver-
wendet werden. Dies aus zwei Gründen: Erstens um dieses Tool kennen zu lernen und zweitens um
es auf seine Tauglichkeit zu testen.
Grundsätzlich werden die Konfigurationsfiles der virtuellen Maschinen in /etc/xen/vm abgelegt. In
/ext/xen befindet sich der Link ‚images‘, welcher auf /var/lib/xen/images verweist. In diesem Ver-
13
zeichnis werden die „Festplatte“ des Gastsystems in Form einer Datei gespeichert .
Ein neues Betriebssystem kann nun, wiederum über den Virtual Machine Manager, auf dem System
installiert werden.
In YaSt sieht das folgendermassen aus:
Abb. 9: Aufstarten des Virtual Machine Managers
Zunächst einmal muss der Punkt ‚Verwaltung von virtuellen Computern (Xen)‘ ausgewählt werden.
Daraufhin wird der Virtual Machine Manager gestartet.
Nach dem Aufstarten des Virtual Machine Managers aus YaSt erscheint das folgende Fenster, in dem
alle bis zu diesem Zeitpunkt installierten virtuellen Maschinen angezeigt und bei Bedarf gestartet (oder
14
gelöscht) werden können :
13
Natürlich ist es auch möglich die Images der Gastsysteme an einem Ort eigener Wahl abzulegen.
14
Leider kann man mit dem Virtual Machine Manager nur Gastmaschinen neu erstellen oder Löschen.
Bereits vorhandene Gastsysteme neu konfigurieren funktioniert nicht, da man nachträglich keinen Zugriff mehr
auf die Konfigurationsparameter erhält.
Harry Giger 16FHNW Seminar: IT-System-Management
Projekt: Xen using VT/Pacifica extensions
Abb. 10: Der Virtual Machine Manager
Durch Klicken des Hinzufügen-Buttons können nun neue virtuelle Maschinen auf dem System instal-
liert werden. Nach dem Klicken dieses Buttons erscheint zunächst das Fenster
Abb. 11: Schritt 1 beim Erstellen einer neuen virtuellen Maschine
Hier kann die Voreinstellung ‚Betriebssysem-Installationsprogramm ausführen‘ belassen werden.
Nach einem Klick auf den Weiter-Button erscheint das folgende Fenster:
Harry Giger 17FHNW Seminar: IT-System-Management
Projekt: Xen using VT/Pacifica extensions
Abb. 12: Übersicht über die Default-Einstellung des Systems
Dieses Fenster stellt die Übersicht über die Voreinstellungen, die vom System her vorgegeben sind,
dar. Diese Voreinstellungen können nun nach eigenen Vorstellungen abgeändert werden.
Beim Klick auf die Schrift ‚Virtualisierungsmodus‘ zum Beispiel, erscheint das Fenster
Abb. 13: Auswahl des Visualisierungsmodus
Beabsichtigt man ein (natürlich unverändertes) Windowssystem als Gast in Xen zu installieren, so
muss hier die Option ‚Vollständige Virtualisierung‘ ausgewählt werden.
Der Name des neuen Gastsystems kann bei ‚VM-Eigenschaften‘ eingegeben werden. Ein weiterer
wichtiger Punkt ist die Definition der neuen ‚virtuellen‘ Festplatte, in der das Gastsystem laufen soll.
Sie wird im Punkt ‚Festplatten‘ definiert.
Harry Giger 18FHNW Seminar: IT-System-Management
Projekt: Xen using VT/Pacifica extensions
Abb. 14: Eine virtuelle Festplatte definieren
Durch Anklicken des Hinzufügen-Buttons kann eine neue Festplatte hinzugefügt, bzw. durch Anklik-
ken des Bearbeiten-Buttons eine bereits bestehende virtuelle Festplatte bearbeitet werden.
Nach der Auswahl von Hinzufügen erscheint folgendes Fenster:
Abb. 15: Eine vituelle Festplatte hinzufügen
Hier die Option ‚Neues Datenträger-Image erstellen‘ auswählen. Alternativ kann man natürlich auch
selber ein Image erstellen und dieses dann übernehmen. Nach dem Klick auf Weiter erscheint folgen-
des:
Harry Giger 19FHNW Seminar: IT-System-Management
Projekt: Xen using VT/Pacifica extensions
Abb. 16: Ein neues Image definieren
In diesem Fenster kann nun die gewünschte Grösse, der Name und das Verzeichnis in dem die virtu-
elle Festplatte, also die Verzeichnis-Struktur des installierten Gastsystems, erstellt wird angegeben
werden.
Standardmässig ist es das Verzeichnis /var/lib/xen/images, es kann aber problemlos ein anderes
Verzeichnis ausgewählt werden.
Nach dem Klick auf ‚Weiter‘ gelangt man zur Auswahl des Installationsmediums. Hier kann man wäh-
len zwischen der Installation ab einer CD/DVD, einem Image oder einer alternativen Installationsquel-
le:
Abb. 17: Das Installationsmedium wählen
Nach einem Klick auf ‚Weiter‘ gelangt man wieder in die Übersicht der neuen virtuellen Maschine, die
dann zum Beispiel so aussieht:
Harry Giger 20FHNW Seminar: IT-System-Management
Projekt: Xen using VT/Pacifica extensions
Abb. 18: Finale Übersicht
Durch einem weiteren Klick auf ‚Weiter‘ wird nun das neue Gastsystem auf der Maschine eingerichtet.
Achtung!
Es wird ein Dialogfenster angezeigt, das einem mitteilt, dass das Gastsystem nun in einer separaten
Konsole installiert wird und die Bootparameter entsprechend gesetzt werden. In diesem Dialogfenster
sollte kein Button gedrückt werden, da sonst der Installationsvorgang abgebrochen wird.
Erst am Schluss (nach ca. 3 Minuten), wenn das Fenster der separaten Konsole verschwunden ist,
kann der Fortsetzen-Button gedrückt werden.
Gestartet werden können die Gastsysteme nun über den Button ‚Starten‘ im Eröffnungsbildschirm des
Virtual Maschine Managers.
Harry Giger 21FHNW Seminar: IT-System-Management
Projekt: Xen using VT/Pacifica extensions
Starten des Gastsystems auf die konventionelle Art
Natürlich kann nun das Gastsystem auch auf die konventionelle Art, d.h. ohne den Virtual Maschine
Manager gestartet werden.
Dafür muss man nur das vom Virtual Maschine Manager erstellte Konfigurationsfile und den entspre-
chenden Befehl von Xen benutzen.
15
Das vom ‚Virtual Machine Manager‘ erstellte Konfigurationsfile hat das folgende Aussehen :
# Ort des Verzeichnisses, in dem die virtuelle Harddisk abgelegt ist
disk = [ 'file:/home/heidi/images/winXPsp2/hda,ioemu:hda,w', 'phy:/dev/hdb,hdc:cdrom,r' ]
# Verfügbares RAM der virtuellen Maschine
memory = 256
vcpus = 1
# Funktionen zur vollen Virtualisation laden
builder = 'hvm'
device_model = '/usr/lib/xen/bin/qemu-dm'
kernel = '/usr/lib/xen/boot/hvmloader'
# Der Name der virtuellen Maschine
name = 'winXP'
# DHCP soll verwendet werden, darum muss die MAC-Adresse angegeben werden
vif = [ 'type=ioemu,mac=aa:16:3e:36:f1:32, bridge=xenbr0' ]
stdvga = 0
sdl = 1
vnc = 0
vncviewer = 0
ne2000 = 0
# Das Verhalten der Maus im Gast verbessern
usb = 1
usbdevice = ‚tablet‘
# Das Gastsystem soll die Systemzeit des Hostsystems übernehmen
localtime = 1
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'
boot = 'c'
15
Mit Kommentaren zur Erklärung ergänzt.
Harry Giger 22FHNW Seminar: IT-System-Management Projekt: Xen using VT/Pacifica extensions Dieses Konfig. File mit dem Namen winXP befindet sich im Verzeichnis /etc/xen/vm. Das zugehörige Gastsystem kann nun mit dem folgenden Befehl gestartet werden: # cd /etc/xen/vm # xm create winXP Mit dem Befehl xm list können die aktuell gestarteten Gastsysteme aufgelistet werden: # xm list Name ID Mem(MiB) VCPUs State Time(s) Domain-0 0 255 2 r----- 1918.7 winXP 5 256 1 -b---- 5.4 Soll ein laufendes Gastsystem von der Konsole aus beendet werden, so wird der Befehl: # xm destroy verwendet. Ebenfalls schon voll funktionstüchtig ist das ‚Networking‘. Standardmässig ist Bridging aktivert, d.h. es wird von Xen eine virtuelle Bridge eingerichtet, über die das Hostsystem und die Gastsysteme mit dem LAN verbunden werden. Ist die Host-Maschine in ein Netzwerk integriert und läuft in diesem Netzwerk ein DHCP-Server, so sollte dem Windows-Gastsystem nach dem Aufstarten automatisch eine IP-Adresse zugewiesen wor- den sein (da bei Windows-Systemen dhcp per default aktiviert ist). Natürlich ist es auch ohne Probleme möglich dem Windows-Gastsystem eine eigene IP-Adresse zu zuweisen, sie muss dann einfach im entsprechenden Dialogfeld definiert werden. Hinweis! Zu einem Problem könnten zwei Netzwerkkarten in der Maschine bzw. zwei auf dem Motherboard integrierte Netzwerkanschlüsse führen, da der virtuellen Xen-Bridge eventuell das falsche Interface zugeordnet wird. Im Rahmen dieser Arbeit musste einer der beiden Netzwerk-Anschlüsse des Motherboards im BIOS desaktiviert werden, da ohne diese Massnahme das Networking nicht funktioniert hat. Harry Giger 23
FHNW Seminar: IT-System-Management
Projekt: Xen using VT/Pacifica extensions
7. Fazit
Arbeiten mit Xen ist eine wirklich interessante Angelegenheit. Das hineindenken in die Materie bringt
einem viele Kenntnisse über Betriebsysteme, Prozessoren und natürlich die Technik der Visualisie-
rung. Auch wenn das Produkt Xen noch am Anfang seiner Karriere steht, so erscheint es durchaus
ziemlich ausgereift, vor allem seit der Version 3.0.
Ebenso gelingt die Installation eines unveränderten Gast nahezu mühelos über das von Suse 10.2
integrierte Tool ‚Virtual Maschine Manager‘. Dies überrascht umso mehr, da auch dieses Tool eine
ziemliche Neuentwicklung von Suse ist und man ja die Gefahren beim verwenden von Neuentwick-
lungen im Allgemeinen kennt.
Nach der Installation von Windows als Gastsystem (z.B. Windows XP) laufen sowohl das Hostsystem
16
als auch das Gastsystem problemlos parallel . Auch das Netzwerk via Bridging läuft ohne grösseres
dazutun einwandfrei.
Der nächste Schritt wäre nun, das Gastsystem einem intensiven Benchmark-Test zu unterziehen, um
zu prüfen, ob sowohl die Xen-Virtualisierung als ganzes, als auch die Zusammenarbeit von Xen mit
der neusten Prozessoren-Generation von (in diesem Fall) Intel das leistet, was allgemein versprochen
wird.
Die Leute von Xen haben es durch die Zusammenarbeit mit den Leuten aus der Prozessor-Industrie
(vorallem Intel) geschafft, das Beste aus zwei Welten zu erschaffen. Zum einen ist Xen eine Umge-
bung die es schafft, leistungsfähige Gastsysteme zu verwirklichen, zum anderen müssen diese Gast-
systeme nicht einmal mehr verändert werden, um den hohen Leistungsansprüchen gerecht zu wer-
den. Addiert man noch die Möglichkeiten dazu, die sich einem im Umfeld der IT-Systemaministration
bieten (siehe Abschnitt „Der Nutzen von virtuellen Maschinen“), so eröffnet sich einem eine riesige
Spielwiese der verschiedensten Einsatz-Szenarios.
Aber Achtung! Wo Licht ist, ist bekanntlich auch Schatten. Denn hinter all diesen positiven Aspekten
17
lauern schon die ersten Gefahren .
The Threat: A Hypervisor-Based Rootkit
The threat, which was the subject of two presentations at Black Hat 2006, is that someone with admi-
nistrator privileges on a system that has hardware-assisted virtualization enabled and no virtualization
software installed can install a hypervisor-based rootkit. This hypervisor-based rootkit would then be
running at a higher privilege level than the operating system itself. The advantage that a hypervisor-
based rootkit offers to an attacker is the reduced ability of legitimate kernel-mode code to detect the
attacker's hypervisor-mode code.
A system that has a legitimate hypervisor installed is not susceptible to this attack, because as soon
as a hypervisor has enabled and used the processor virtualization extensions, a second hypervisor
cannot use the extensions.
16
Hier muss natürlich gesagt werden, dass das System sicher nicht auf Biegen und Brechen getestet wurde, das
sollte eher im Rahmen einer Diplomarbeit abgehandelt werden.
17
Quelle: http://www.microsoft.com/whdc/system/platform/virtual/CPUVirtExt.mspx
Harry Giger 24FHNW Seminar: IT-System-Management
Projekt: Xen using VT/Pacifica extensions
18
Hierzu noch folgendes zur Definition eines rootkit’s :
Ein Rootkit (engl. etwa: „Administratorenausrüstung“; root ist unter unixähnlichen Betriebssystemen
der Benutzer mit Administratorrechten) ist eine Sammlung von Softwarewerkzeugen, die nach dem
Einbruch in ein Computersystem auf dem kompromittierten System installiert wird, um zukünftige
Logins des Eindringlings zu verbergen und Prozesse und Dateien zu verstecken.
Der Begriff ist heute nicht mehr allein auf unixbasierte Betriebssysteme beschränkt, da es inzwischen
auch Rootkits für Nicht-Unix-Systeme gibt. Antivirensoftware versucht, die Ursache der Kompromittie-
rung zu entdecken. Zweck eines Rootkits ist es, Malware vor den Antivirenprogrammen und dem Be-
nutzer zu verbergen (zu tarnen).
Ein Rootkit versteckt normalerweise Logins, Prozesse und Logs und enthält oft Software, um Daten
von Terminals, Netzwerkverbindungen und der Tastatur abzugreifen. Hinzu können Backdoors (Hin-
tertüren) kommen, die es dem Angreifer zukünftig vereinfachen, auf das kompromittierte System zu-
zugreifen, indem beispielsweise eine Shell gestartet wird, wenn an einen bestimmten Netzwerkport
eine Verbindunganfrage gestellt wurde. Die Grenze zwischen Rootkits und Trojanischen Pferden ist
fließend.
Es ist nicht alles Gold, was glänzt. Darum unbedingt folgendes beachten:
Hat man nicht im Sinn eine mit der ‚Intel Virtualization Technology‘ ausgerüstete Maschine für Virtuali-
sierung zu nutzen, so sollte die IVT-Funktionalität im BIOS auf disable umgestellt werden.
8. Quellen
http://en.wikipedia.org/wiki/Virtual_machine
http://en.wikipedia.org/wiki/IBM_M44/44X
http://www.computerwoche.de/produkte_technik/software/587715/index2.html
http://www.nodemaster.de/xen-grundlagen/
http://eclipt.uni-klu.ac.at/ecliptwiki/LinuxDay2007/Virtualisierung/060_Xen
http://www.tecchannel.de/technologie/prozessoren/402566/index4.html
http://www.microsoft.com/whdc/system/platform/virtual/CPUVirtExt.mspx
http://de.wikipedia.org/wiki/Rootkit
18
Quelle: http://de.wikipedia.org/wiki/Rootkit
Harry Giger 25Sie können auch lesen
