Die Virtualisierung von Computern erfreut sich zunehmender Beliebtheit. Mehrere Betriebssysteme arbeiten parallel und unabhängig voneinander auf einem PC. Die Realisierung übernehmen Software-Lösungen wie VMware ESX Server oder Microsofts Virtual PC.
Allerdings müssen die Software-Pakete komplexe Klimmzüge machen, um einen Rechner in virtuelle PCs zu unterteilen. Nicht nur die Performance, auch die Betriebssicherheit sinken dadurch. AMD unterstützt mit „Pacifica“ die Virtualisierung des Prozessors auf Hardware-Ebene. Damit arbeitet für Pacifica angepasste Virtualisierungs-Software mit deutlich weniger Overhead. Positive Folge: mehr Geschwindigkeit und höhere Stabilität.
Mit der „Secure Virtual Machine Architecture“, so der richtige Name, geht AMD noch einen Schritt weiter. Denn im Prozessor integrierte Trusted-Computing-Features sorgen zusätzlich für mehr Security. Außerdem virtualisiert Pacifica den Speicher-Controller.
Auf dem Fall Processor Forum in San Jose, Kalifornien, konnte tecCHANNEL ausführlich mit Kevin McGrath, AMD Senior Fellow und Chief Architect der AMD64-Architektur, über die Pacifica-Technologie diskutieren. In diesem Artikel fassen wir die Funktion und die Features von AMDs CPU-Virtualisierung zusammen. Außerdem weisen wir auf die Unterschiede zu Intels konkurrierender Vanderpool-Technologie hin.
Prinzip der Virtualisierung
Virtualisierung auf einem PC arbeitet meist nach dem folgenden Prinzip: Eine so genannte Virtual-Machine-Software erzeugt auf einem Host-Rechner emulierte PCs. Diese emulierten Rechner verfügen über alle notwendigen Elemente wie Prozessor, Festplatte, Grafikkarte und Tastatur. Innerhalb dieses geschlossenen Systems kann ein Betriebssystem gestartet werden, das auf die virtuelle Hardware zugreift, als sei es ein echter Computer, ohne den Unterschied zu bemerken.
In der Praxis gestaltet sich diese Aufgabe jedoch erheblich schwieriger. Immerhin gilt es, eine Vielzahl von benötigten Komponenten virtuell zu erzeugen. Da das Betriebssystem auf dem Host-Rechner den exklusiven Zugriff auf die Hardware behält, kann eine VM-Software dem Gastbetriebssystem keinen direkten Zugriff auf die reale Hardware gewähren. Deshalb findet das Betriebssystem in der virtuellen Maschine auch eine andere Hardware vor, als tatsächlich im PC eingebaut ist.
So gibt es beispielsweise einen emulierten Chipsatz sowie als Grafikkarte eine S3 Trio. Eine tatsächlich im System vorhandene GeForce 7800 steht den virtuellen Maschinen nicht zur Verfügung.
Simulierte CPU
Die VM-Software muss den VMs - den virtuellen Maschinen - somit auch virtuelle Prozessoren vorgaukeln. Nur so kann der Host die volle Kontrolle über den Prozessor behalten. Leider bedingt dies, dass den virtuellen Maschinen simulierte CPUs mit eingeschränkter Funktionalität zur Verfügung stehen. Die VM-Software bietet dann den VMs beispielsweise keinen SMP-Support oder Features wie die 64-Bit-Befehlserweiterung. Auch steht den VMs durch die "Software-CPUs" weniger Prozessor-Performance als beim Original zur Verfügung. Hätten die VMs aber vollen Zugriff auf die "Original-CPU", so könnten sie sich gegenseitig beeinflussen und Abstürze verursachen.
Mit der Secure Virtual Machine Architecture „Pacifica“ will AMD dieses Problem bei den eigenen Prozessoren aus der Welt schaffen. AMD64-CPUs mit der Secure Virtual Machine Architecture erhalten den so genannten SVM-Befehlssatz. Die neuen Befehle bieten virtuellen Maschinen Prozessor-Level-Support. Pacifica ermöglicht der VM-Software eine einfachere und sichere Verwaltung der Prozessor-Ressourcen.
Intels konkurrierende Vanderpool-Lösung mit der Bezeichnung VT-x für IA32-CPUs und VT-i für Itaniums erhalten den so genannten VMX-Befehlssatz.
Virtueller Prozessor
Die CPU ist der Hauptbestandteil des echten und des virtuellen PCs. AMDs AMD64- sowie Intels IA32-Architektur haben allerdings hinsichtlich der Abbildung virtueller Maschinen gegenüber den Mainframes einige Schwächen. Letztere sind schon architektonisch auf virtuelle Maschinen ausgelegt.
AMDs Prozessoren mit AMD64-Architektur bieten vier verschiedene Privilegien an, mit denen dem Betriebssystem sowie den Treibern und Programmen unterschiedliche Rechte zugewiesen werden können. Normalerweise laufen das Betriebssystem und die Treiber im so genannten Ring 0 (Kernel Mode) und Applikationen im Ring 3 (User Mode). Diese "Current Privilege Levels" werden auch mit CPL 0 beziehungsweise CPL 3 bezeichnet. Der Trick beim Erzeugen eines virtuellen Systems besteht darin, dieses nicht mit CPL 0 ablaufen zu lassen.
Wenn das Betriebssystem des virtuellen Rechners nun einen Befehl ausführen will, der nur im Ring 0 (CPL 0) gestattet ist, löst der Prozessor eine Exception aus. Routinen zur Behandlung dieser Ausnahmen können dann den privilegierten Befehl emulieren. Dabei behält das Wirtsystem die volle Kontrolle über das System. Die wichtigste Voraussetzung für das Funktionieren dieses Ansatzes ist, dass der Prozessor bei jeder unberechtigt durchgeführten privilegierten Anweisung eine Exception auslöst.
Leider sind die x86-Prozessoren nicht ganz so gründlich bei den Exceptions. Beispielsweise werden Speicherzugriffe beim x86 über eine GDT (Global Descriptor Table) abgewickelt. Diese GDT ist eine globale Ressource und wird vom Betriebssystem verwaltet. Eigentlich müsste jeder direkte Zugriff auf diese Ressource als privilegierte Handlung angesehen werden und dementsprechend im User Mode nicht erlaubt sein. Der x86 behandelt die LGDT-Anweisung (Load Global Descriptor Table) auch als privilegiert. Allerdings führt SGDT (Store Global Descriptor Table) nicht zu einer Schutzverletzung. Allein diese Inkonsistenz verhindert es, die GDT zu "virtualisieren".
AMDs Pacifica-Technologie greift hier ein und erleichtert unter anderem auch das Exceptions-Handling. VM-Software mit Pacifica-Support lässt sich somit einfacher programmieren - bei gleichzeitig höherer Betriebssicherheit und mehr Performance.
SVM-Operationen
AMD unterstützt die Virtualisierung auf Prozessorebene durch eine neue Form von CPU-Operationen mit der Bezeichnung SVM (Secure Virtual Machine). VM-Software wie beispielsweise VMware Workstation arbeiten dabei weiterhin im „normalen“ Prozessormodus. AMD bezeichnet diesen Host auch als Virtual Machine Monitor VMM oder Hypervisor. Der VMM/Hypervisor besitzt die volle Kontrolle über den Prozessor und die übrige Hardware des PCs. Die virtuellen Maschinen beziehungsweise die Gast-Software arbeiten im neuen CPU-Mode „Guest“.
Ein VMM kann den Prozessor durch den SVM-Befehl „VMRUN“ veranlassen, im Guest-Modus zu arbeiten. Dabei ist der VMRUN-Befehl nur im CPL-0-Ring verfügbar. Der Übergang zurück aus dem Guest-Modus erfolgt mit "#VMEXIT“. Die Funktionalität eines Pacifica-Prozessors im normalen Betriebsmodus entspricht dabei einer CPU ohne SVM-Unterstützung. Der Unterschied einer Pacifica-CPU liegt in den zusätzlich verfügbaren SVM-Befehlen. Das Verhalten des Prozessors im Guest-Modus lässt sich durch SVM kontrollieren. So verursachen bestimmte Befehle oder Situationen einen #VMEXIT.
Dabei ist es für Gast-Software nicht möglich, seinen Betrieb im Guest-Modus zu erkennen. Durch SVM behält der Hypervisor auch die Kontrolle über VM-Software, die mit CPL 0 arbeitet. Mit SVM besitzt der VMM einfach ausgedrückt einen höheren "Privilege Level" als CPL 0. Diese Fähigkeit erleichtert die Programmierung eines VMM, weil die Gast-Software stets in dem "Privilege Level" arbeiten kann, für die sie entwickelt wurde.
Initialisierung
Ob ein AMD64-Prozessor SVM unterstützt, kann die Host-Software über die CPUID-Funktion 8000_000Ah abfragen. In das EAX-Register übergebene Werte signalisieren dann die SVM-Präsenz sowie die Version von SVM.
Will ein VMM den Guest-Modus des Prozessors verwenden, muss er ihn erst aktivieren. Dies erfolgt über das Setzen des Bit 12 im EFER-MSR-Register (EFER.SVME) auf den Wert 1. Danach lassen sich durch den Befehl VMRUN die SVM Extensions verwenden. Soll der Prozessor den Guest-Modus verlassen, muss ein #VMEXIT Ereignis von der System-Software verwendet werden. Bei Intels Vanderpool heißen die entsprechenden VT-x-Befehle VMXON und VMXOFF. Den Guest-Modus bezeichnet Intel dabei als VMX-Non-Root-Modus.
Vor dem Ausführen des VMRUN-Befehls muss die Host-Software einen 4 KByte großen Speicherbereich für SMV-Operationen reservieren. Die Adresse dieser Speicherregion wird einem Operanten des VMRUN-Befehls übergeben. In diesem 4-KByte-Bereich sind alle relevanten Informationen des Prozessors und des Betriebssystems einer VM gespeichert.
SVM-Kontrolle
Die Kontrolle über die SVM-Guest-Workloads übernimmt eine neue Datenstruktur mit der Bezeichnung „Virtual Machine Control Block“ VMCB. Bei Intel heißt das entsprechende Pendant „Virtual Machine Control Structur“ VMCS.
Der VMCB von Pacifica zeichnet für die Übergänge in und aus dem Guest-Modus ebenso verantwortlich wie für den Prozessor im "Gastmodus" selbst. Über die neuen SVM-Befehle VMLOAD und VMSAVE lässt sich das VMCB bearbeiten (siehe auch SVM-Befehle im Überblick).
Der Prozessor verknüpft jedes VMCB-Register mit einer 64 Bit breiten physikalischen Adresse - und dem bereits erwähnten 4 KByte großen Block. Die Aktivierung eines VMCB - und somit einer virtuellen Maschine - erfolgt über den SVM-Befehl VMRUN mit zugehöriger Adresse im rAX-Register. Diese VMCB bleibt dann für die Kontrolle des Prozessorverhaltens in einer Gast-Software verantwortlich. Von der Host-Software können dabei je nach Bedarf an virtuellen Maschinen mehrere VMCB per VMRUN [rAX] mit unterschiedlichen Adressen angelegt werden.
Ein VMCB ist in zwei Gruppen unterteilt: die erste enthält verschiedene Kontroll-Bits und die zweite speichert den Status eines Guest-Modus. Die letztgenannte Gruppe enthält beispielsweise Informationen über die Ursachen und Art eines #VMEXIT, wenn also eine virtuelle Maschine beendet wird. Zum Auslesen und Schreiben der VMCB-Datenfelder sind wie bereits erwähnt die Befehle VMLOAD und VMSAVE zu verwenden.
In künftigen Versionen von Pacifica will AMD den Guest-Status lokal im Prozessor statt im Speicher sichern. Damit soll ein schnellerer Wechsel zwischen den VMs und dem Hypervisor möglich werden.
SVM-Befehle im Überblick
AMDs Pacifica-Technologie mit den Secure Virtual Machine Extensions SVM verfügt über neun neue Befehle. Dabei dienen die Instruktionen dem Verwalten des Virtual Machine Control Block VMCB und führen SVM-Operationen durch.
CLGI: Löscht das Global Interrupt Flag (GIF). Solange GIF den Wert 0 besitzt, sind alle externen Interrupts unzulässig.
INVLPGA: Setzt den TLB-Eintrag einer virtuellen Page zurück. Die virtuelle Adresse wird im rAX-Register übergeben.
MOV (CRn): Schreibt den Inhalt der allgemeinen 32- oder 64-Bit-Register (GPR) in ein Control-Register.
SKINIT: Bereitet den Prozessor für den Einsatz von Trusted Software vor.
STGI: Die Instruktion setzt das Global Interrupt Flag (GIF) auf den Wert 1. Damit sind externe Interrupts zugelassen.
VMLOAD: Setzt den Prozessor auf einen Status, der im VMCB gespeichert ist. Die Adresse des VMCB wird über das rAX-Register eingelesen.
VMMCALL: Befehl erlaubt einer Gast-Software die Kommunikation mit dem Hypervisor.
VMRUN: Startet die Ausführung von Befehlsfolgen im Guest-Modus. Die physikalische Adresse des VMCB, in dem die virtuelle Maschine beschrieben wird, steht im rAX-Register.
VMSAVE: Der Befehl schreibt ein Subset des Prozessor-Guest-Status in das VMCB. Die Adresse des VMCB ist im rAX-Register spezifiziert.
Virtualisierter Speicher-Controller
AMDs AMD64-Prozessoren unterscheiden sich durch ihren integrierten Memory-Controller von Intels x86-CPUs. Hier hebt sich Pacifica auch wesentlich von Intels Vanderpool-Technologie ab, indem der Speicher-Controller ebenfalls virtualisiert wird.
Normalerweise arbeitet jede VM in einem eigenen Adressbereich, den der Hypervisor/VMM unter Kontrolle behält. Die Adressanfragen einer VM übersetzt der Hypervisor/VMM und lenkt sie auf entsprechend zugewiesene physikalische Adressen um. Werden die Daten aus dem Speicher gelesen, so muss sie die Virtualisierungs-Software erneut für die virtuelle Maschine umleiten. Diese bei Intels Vanderpool praktizierte Lösung ist Software-basierend und kostet Zeit.
Pacifica kann diesen Vorgang mit Hardware-Unterstützung erledigen. So gibt es in der SVM-Architektur den neuen Speicher-Modus „Nested Paging“ mit Nested Page Tables (NPT). In der „normalen“ x86-Architektur sowie in Vanderpool-CPUs gibt es ein CR3-Register, das die physikalische Adresse des Page Tables speichert. Der Page Table regelt dann in Zusammenarbeit mit der Memory Managing Unit (MMU) der CPU die Adress-Übersetzung.
Der Nested-Paging-Modus von Pacifica stellt dagegen jeder VM ein eigenes virtualisiertes CR3-Register zur Verfügung. Dieses so genannte gCR3 wird bei jedem VM-Ein- und Austritt geladen und gespeichert. Die Ergebnisse sind im TLB gepuffert. Es wird mit den Nested Paging zwar eine zusätzliche Übersetzungsschicht eingeführt, die Vorgänge erfolgen aber Hardware-basierend und somit mit höherer Effizienz. Außerdem reduziert der Einsatz von Nested Paging die Frequenz von #VMEXIT.
Die beim Einsatz von virtuellen Maschinen ständig notwendigen Adressübersetzungen wandern mit Pacifica von der Software-Emulation in die Hardware. Besonders Betriebssysteme und Applikationen mit hohem Speicherbedarf sollten von NPT profitieren.
Laut AMD werden aber nicht alle Pacifica-CPUs das Feature Nested Page Tables besitzen. Über die CPUID-Funktion 8000_000Ah lässt sich die Nested-Paging-Funktionaliät abfragen.
Neuer CPU-Mode: Paged Real Mode
Intels VMX-Operationen setzten - wie auch AMDs SVM-Operationen - den Page-protected Mode des Prozessors voraus. Dies ist durch die bei VMX notwendigen Einschränkungen bei den Registerbits CRO.PE und CRO.PG notwendig. Der Betrieb von Gast-Software im Unpaged-protected Mode oder im Real-Address Mode ist somit nicht möglich. Soll ein VMM entsprechende Gast-Software trotzdem unterstützen, muss vom VMM eine Emulation dieser Modi erfolgen. Hierzu kann ein VMM bei Vanderpool die "Identify Page Tables" für die Emulation verwenden.
AMDs SVM-Architektur stellt dagegen den neuen Prozessor-Modus „Paged Real Mode“ zur Verfügung. Der Modus erlaubt die Virtualisierung des Real Mode. Pacifia-CPUs können in virtuellen Maschinen somit Real-Mode-Anwendungen ohne Emulation laufen lassen.
Die SVM-Architektur nutzt dabei zusätzlich ein Paging, ohne dass die Gast-Software davon etwas bemerkt. Die VM sieht somit eine Real-Adressierung. Die Integration des Paged Real Mode in der Hardware des Prozessors erhöht die Effizienz dieses Methode gegenüber einer Emulation.
Device Exclusion Vector
Ein weiteres Feature von Pacifica gegenüber Intels Vanderpool-Technologie stellt der Device Exclusion Vector (DEV) dar. DEV behandelt in virtuellen Maschinen DMA-Zugriffe und Geräte die DMA benötigen. DMA-fähige Geräte greifen direkt auf den Speicher des Systems ohne Hilfe des Prozessors zu. Nur die Initialisierung des Speicherzugriffs erfolgt weiterhin über die CPU.
Der Device Exclusion Vector der SVM-Architektur bietet in VMs einen Schutz vor dem Zugriff DMA-fähiger Geräte auf den physikalischen Speicher (Page-Basis). Die Regelung übernimmt eine Control-Logik in der Host Bridge der im Prozessor integrierten Northbridge.
Die Host Bridge unterstützt in der ersten Implementation von Pacifica vier so genannte Protection Domains. Jede Protection Domain ist mit einem DEV gekoppelt. Die Identifikation von DMA-fähigen Devices erfolgt über eine Unit-ID des HyperTransport-Busses. Die Host Bridge weist über diese ID-Erkennung die entsprechenden Protection Domains zu.
Bei jedem DMA-Zugriff überprüft AMDs Pacifica-Technologie über den Device Exclusion Vector somit die Gültigkeit. Der DEV ist somit ein simpler Mechanismus, um die Programmierung einer Hypervisor-Software zu vereinfachen.
Integriertes Trusted Computing
AMD integriert in die Pacifica-Technologie erste Security-Features für Trusted-Computing. Entsprechend entschied sich AMD auch für die Bezeichnung Secure Virtual Machine Architecture. Damit bereitet der Hersteller mit Pacifica die Einführung der schon angekündigten Trusted-Computing-Technologie „Presidio“ vor.
Für die Virtualisierung des Prozessors sind die Securtiy-Features allerdings nicht notwendig. Mit dem SVM-Befehl SKINIT wird aber das Starten von Trusted Software in einer virtuellen Maschine möglich. SKINIT reinitialisiert die CPU zum Bereitstellten einer gesicherten Arbeitsumgebung. Diese von AMD als „Secure Loader“ bezeichnete Umgebung ist gegen Zugriffe von außen geschützt.
Der Secure Loader (SL) initialisiert typischerweise Trusted Computing Software wie einen Hypervisor, nachdem die Identität der Software validiert wurde. Der Secure Loader besteht aus einem 64 KByte großen Secure Loader Image. Dieses Image liegt im so genannten Secure Loader Block, einer beliebigen 64-KByte gebundenen Adresse unterhalb von 4 GByte. Das Image enthält alle relevanten Informationen zum gesicherten Starten und Überprüfen eines TPM-Kernels.
Zu einem Vorteil von SKINIT zählt, dass sich mit dem Befehl geschützte Umgebungen einschalten lassen, selbst wenn der Rechner bereits im „Untrusted Mode“ läuft. Dadurch sind keine Änderungen an den typischen Boot-Prozessen von x86-Plattformen notwendig.
Fazit
AMDs Virtualisierungstechnologie „Pacifica“ ist mit Vanderpool von Intel nicht kompatibel. Es stellt sich natürlich zuerst die Frage nach dem „warum“. Die Antwort ergibt sich aus den Architektur-Unterschieden und den damit für AMD verbundenen Möglichkeiten. So hat sich diese Frage laut AMD-Fellow Kevin McGrath auch nicht gestellt.
Denn Prozessoren wie der Athlon 64 und Opteron verfügen über einen integrierten Speicher-Controller sowie direkt via HyperTransport angebundene Devices. Damit ist es für AMD einfacher den Speicher-Controller zu virtualisieren mit Features wie „Nested Paging“. Den Zugriff von DMA-fähigen Geräten in virtuellen Maschinen kontrolliert die CPU über den Device Exclusion Vector. Möglich macht dies die modifizierte integrierte Northbridge.
Diese Möglichkeiten sind für Intel mit dem Prozessor nicht gegeben. Hier müssen Virtualisierungsfunktionen in den Chipsatz wandern. Die Plattform-Strategie von Intel sieht dies in den nächsten Schritten auch vor.
Doch bevor es soweit ist, geht Intel noch im vierten Quartal 2005 mit Vanderpool-fähigen Desktop-Prozessoren an den Start. Im ersten Quartal 2006 folgen die Xeons sowie die Mobile-CPU Pentium M „Yonah“ mit der Virtualisierung.
AMD hält sich mit Aussagen über genaue Zeitpläne zurück. Allerdings war Kevin McGrath ein „ im ersten Halbjahr 2006“ für die Einführung erster Pacifica-CPUs zu entlocken. Außerdem wird Pacifica zusammen mit dem Wechsel auf DDR2-Speicher in den AMD64-Prozessoren Einzug erhalten, wie McGrath weiter verrät. Dies wird „Gerüchten“ zufolge Ende des ersten Quartals 2006 passieren.
Software-Unterstützung wird es sowohl für Pacifica als auch für Vanderpool geben. AMD und Intel betonen dabei stets die gute Zusammenarbeit mit Microsoft, VMware oder XenSource. Intels Vanderpool unterstützende Software ist mit VMwares Workstation 5.5 und Xen 3.0 bereits verfügbar – beide besitzen allerdings noch Beta-Status.
Szenarien für die Virtualisierung gibt es sowohl im Business- als auch Consumer-Segment genügend - beispielsweise für die Migration von einem Betriebssystem zu einem anderen.
In einer VM lassen sich die verwendeten Programme ohne Gefahr mit dem neuen OS testen. Anwendungen, die auf dem neu einzusetzenden Betriebssystem nicht laufen, arbeiten einfach in einer eigenen VM mit dem bisherigen OS weiter. Bei Desktop-PCs im Consumer-Segment wären beispielsweise eigene hoch abgesicherten virtuellen Installationen für den Internet-Zugriff möglich. (cvi)