X86-Virtualisierung: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
 
(23 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
 
=Was ist x86-Virtualisierung?=
 
=Was ist x86-Virtualisierung?=
−
*hardware- und softwarebasierte Mechanismen zur Unterstützung der Virtualisierung für Prozessoren, die auf der x86-Architektur basieren.
+
*Techniken, um mehrere Betriebssysteme gleichzeitig auf einem x86-Prozessor auszuführen.
−
*Unter Verwendung eines Hypervisors kann man mehrere Betriebssysteme parallel auf einem x86-Prozessor auszuführen
+
*Ein Hypervisor verteilt die physischen Ressourcen effizient und isoliert an die VMs.
−
*Man kann die Ressourcen isoliert und effizient zwischen den parallel ausgeführten Betriebssystemen aufteilen.
+
*Ziel: Das Gastbetriebssystem merkt keinen Unterschied zwischen virtueller und physischer Hardware.
−
*Die (Gast-)Betriebssysteme sollten keinen Unterschied zwischen virtualisiertem und den Betrieb direkt auf der Hardware erkennen können.
+
 
−
=Ring Model=
+
=Das Problem: Schutzringe=
−
{{#drawio:ring-model}}
+
*x86-Prozessoren kennen vier Schutzringe (Ring 0–3).
−
=VT Modell=
+
**Das Betriebssystem läuft in Ring 0 und darf alles.
 +
**Anwendungen laufen in Ring 3 und dürfen wenig.
 +
**Ring 1 und 2 werden praktisch nicht genutzt.
 +
*Ein Gast-Kernel erwartet ebenfalls Ring 0. Den belegt aber schon der Host bzw. der Hypervisor.
 +
 
 +
==Früher: Software-Virtualisierung (vor ca. 2006)==
 +
*Keine Unterstützung durch den Prozessor.
 +
*Der Gast-Kernel läuft deprivilegiert, z. B. in Ring 1.
 +
*Der Hypervisor muss kritische Befehle abfangen und per Software nachbilden (Binary Translation, z. B. frühes VMware) oder der Gast-Kernel wird angepasst (Paravirtualisierung, z. B. frühes Xen).
 +
*Nachteil: hoher Overhead durch häufiges Abfangen.
 +
*Nicht verwechseln mit Emulation: Gast und Host haben hier dieselbe Plattform, die CPU wird nicht nachgebaut.
 +
 
 +
=Heute: Hardware-Virtualisierung mit VT-x / AMD-V=
 +
*Der Prozessor bekommt zwei Betriebsmodi:
 +
**'''VMX Root Mode''' („Ring -1“): Hier läuft der Hypervisor mit voller Kontrolle über die Hardware.
 +
**'''VMX Non-Root Mode''': Hier laufen die VMs. Das ist der „Gastmodus“.
 +
*Innerhalb jedes Modus gibt es wieder die Ringe 0–3:
 +
**Das Gastbetriebssystem läuft in seinem eigenen Ring 0, die Anwendungen in Ring 3.
 +
**Der Gast muss dafür nicht angepasst werden.
 +
*Kritische Operationen im Non-Root Mode lösen automatisch einen Wechsel zum Hypervisor aus.
 
{{#drawio:vt-ring}}
 
{{#drawio:vt-ring}}
−
=Thread 1=
 
−
*KVM, das für Kernel-basierte Virtualisierung steht, ist ein Linux-Kernel, der in Kombination mit dem kvm-Kernelmodul den üblichen Linux-Kernel in einen Bare-Metal-Hypervisor verwandelt.
 
−
*Sobald KVM im Kernel installiert ist, können wir virtuelle Maschinen darin erstellen und sie mit verschiedenen Userspace-Tools wie qemu, libvirt oder virsh steuern.
 
−
*CPU-Virtualisierung: Um die CPU zu virtualisieren, nutzt KVM die Hardwarelösung, d. h. CPUs, in die Virtualisierungsanweisungen integriert sind.
 
−
*Intel nennt dies VT-X und AMD nennt es AMD-V.
 
−
*Die traditionelle Architektur von CPUs hatte den standardmäßigen ringbasierten Betrieb, wie unten gezeigt.
 
−
*Das Betriebssystem würde die privilegierten Befehle im Ring 0 ausführen und die Benutzerraumanwendungen würden im Ring 3 ausgeführt.
 
−
*Die Einführung der Virtualisierung erforderte das Vorhandensein einer neuen Schicht zwischen der Hardware und dem Betriebssystem.
 
−
*Dies hätte auf zwei Arten erreicht werden können: 0/1/3-Modell, bei dem das Betriebssystem in Ring 1 verschoben und der Hypervisor in Ring 0 ausgeführt wird
 
−
*0/3/3-Modell, bei dem das Betriebssystem und die Anwendungen beide im Ring3 ausgeführt werden und der Hypervisor im Ring 0 ausgeführt wird.
 
−
*Beide Modelle, die das Betriebssystem von Ring 0 wegbewegen, führen zu mehreren Problemen, da das Betriebssystem so konzipiert ist, dass es immer in Ring 0 ausgeführt wird.
 
−
*Die Softwarelösungen wie binäre Übersetzung und Paravirtualisierung versuchen, die Probleme aufgrund dieser Änderung des Betriebsrings anzugehen das Betriebssystem.
 
−
*Die von Intel und AMD-V eingeführte Hardwarelösung löst dies, indem sie neue Betriebsmodi in der CPU einführt.
 
−
*Die für die Intel-Virtualisierung aktivierte Hardware verfügt über die neuen Betriebsmodi VMX Root und VMX Non Root.
 
−
*Die VMX-Root-Operation wird verwendet, um den Hypervisor auszuführen, und die VMX-Non-Root-Operation wird verwendet, um die VM selbst auszuführen
 
−
*Jeder dieser CPU-Modi hat Ring 0,1,2,3.
 
−
*Somit kann das Betriebssystem weiterhin in ring0 im VMX-Non-Root-Modus arbeiten und somit seine gesamte Kontrolle über die Hardware wie bei einem herkömmlichen Betriebssystem behalten.
 
−
*Der Hypervisor hingegen wird im VMX-Root-Modus in Ring 0 ausgeführt.
 
−
*Somit erhält sogar der Hypervisor die vollständige Kontrolle über die Hardware, indem er im ring0 vorhanden ist.
 
−
*Aber zu jedem beliebigen Zeitpunkt würde entweder die andere VM oder der Hypervisor im Ring-0-Modus arbeiten.
 
−
*Dies löst eine Reihe von Problemen, die in den Softwarelösungen der Virtualisierung bestehen, und macht die Virtualisierung viel schneller,
 
−
*Die VM während des normalen Betriebs ohne Eingriff des Hypervisors direkt auf der Hardware arbeiten kann.
 
−
*Die Steuerung verlagert sich aus der VM nur bei einer E/A, die von der im Host-Kernel laufenden Userspace-Anwendung gehandhabt wird, und bei Interrupts oder anderen Signalen, die vom Hypervisor gehandhabt werden.
 
−
 
−
*KVM nutzt diese Hardwarefunktion, während die virtuellen Maschinen ausgeführt werden.
 
−
*Somit gibt es neben dem traditionellen Kernel-Space und User-Space einen neuen Modus, der als Gast-Betriebsmodus im Kernel bezeichnet wird.
 
−
*Die VM arbeitet in diesem Gastmodus, der den VMX-Nicht-Root-Modus nutzt.
 
−
*Das Gastbetriebssystem arbeitet im Ring 0 des VMX-Non-Root-Modus und die Anwendungen im Gastbetriebssystem im Ring 3 des VMX-Non-Root-Modus.
 
−
*Der KVM-Kernel hingegen arbeitet im Ring 0 des VMX-Root-Modus.
 
−
*Der Kernel, der als Hypervisor fungiert, wird im Kernelraum des vmx-Root-Modus ausgeführt.
 
  
 +
==Ablauf: VM-Entry und VM-Exit==
 +
*'''VM-Entry:''' Der Hypervisor wechselt in die VM (Root → Non-Root). Ab jetzt rechnet der Gast direkt auf der CPU.
 +
*'''VM-Exit:''' Bei privilegierten Befehlen oder Gerätezugriffen springt die CPU automatisch zurück zum Hypervisor (Non-Root → Root).
 +
*Der Hypervisor erledigt die Aufgabe und startet die VM mit dem nächsten VM-Entry wieder.
 +
*'''VMCS''' (Virtual Machine Control Structure): Pro VM speichert die CPU deren Zustand (Register, Speicherverwaltung) und den Zustand des Hypervisors. Dadurch geht der Wechsel schnell.
 +
*'''Speicher und I/O:''' Der Hypervisor trennt den Speicher der VMs voneinander. Mit '''EPT''' (Intel) bzw. '''NPT''' (AMD) übersetzt die CPU auch die Speicheradressen der VM selbst. Gerätezugriffe werden emuliert (z. B. durch QEMU) oder an echte Geräte weitergereicht.
 +
{{#drawio:Ausführungsebenen}}
  
 +
;Am Beispiel KVM
 +
*KVM ist der Hypervisor im VMX Root Mode, die VM läuft im Non-Root Mode.
 +
*QEMU emuliert die Geräte der VM. Gerätezugriffe landen per VM-Exit bei KVM und werden an QEMU weitergegeben.
  
 +
=Hardwareerweiterungen=
 +
*'''Intel VT-x''': CPU-Flag <code>vmx</code>
 +
*'''AMD-V''' (auch SVM): CPU-Flag <code>svm</code>
 +
*Beide arbeiten nach demselben Prinzip.
 +
grep -m1 -owE 'vmx|svm' /proc/cpuinfo
 +
*Keine Ausgabe = im BIOS/UEFI abgeschaltet oder nicht vorhanden.
  
−
=Thread 2=
+
=Praxis-Beispiele=
−
*VT-x ist eine CPU-Virtualisierung für die Intel 64- und IA-32-Architektur.
+
*[[KVM]] (Kernel-based Virtual Machine, Linux)
−
*Für Intels Itanium gibt es VT-I.
+
*VMware vSphere (ESXi)
−
*Für die I/O-Virtualisierung gibt es VT-d.
+
*Microsoft Hyper-V
−
*Unter VT-x arbeitet eine CPU in einem von zwei Modi: Root und Nicht-Root.
+
*Citrix XenServer
−
*Diese Modi sind orthogonal zu Real, Protected, Long usw. und auch orthogonal zu Privileg-Ringen (0–3).
 
−
*Sie bilden sozusagen eine neue „Ebene“.
 
−
*Hypervisor wird im Root-Modus ausgeführt und VMs werden im Nicht-Root-Modus ausgeführt.
 
−
*Im Nicht-Root-Modus wird CPU-gebundener Code meistens genauso ausgeführt wie im Root-Modus,
 
−
*Was bedeutet, dass die CPU-gebundenen Operationen der VM größtenteils mit nativer Geschwindigkeit ausgeführt werden.
 
−
*Es hat jedoch keine volle Freiheit.
 
−
*Privilegierte Befehle bilden eine Teilmenge aller verfügbaren Befehle auf einer CPU.
 
−
*Dies sind Anweisungen, die nur ausgeführt werden können, wenn sich die CPU in einem höher privilegierten Zustand befindet,
 
−
*z. aktuelle Berechtigungsebene (CPL) 0 (wobei CPL 3 am wenigsten privilegiert ist).
 
−
*Eine Teilmenge dieser privilegierten Anweisungen können wir „globale zustandsändernde“ Anweisungen nennen – diejenigen, die den Gesamtzustand der CPU beeinflussen.
 
−
*Beispiele sind solche Befehle, die Takt- oder Interrupt-Register modifizieren oder auf eine Weise in Steuerregister schreiben, die den Betrieb des Root-Modus ändern.
 
−
*Diese kleinere Teilmenge sensibler Anweisungen kann der Nicht-Root-Modus nicht ausführen.
 
  
−
=Softwarebasierte Virtualisierung=
+
=Weiterführende Informationen=
−
*Es darf nur dem Hypervisor direkter Zugriff auf die Prozessor-Hardware gewährt werden
+
*[https://tuxthink.blogspot.com/2011/12/kvm-introduction.html Einführung in KVM (tuxthink)]
−
*Gastsysteme wie alle anderen Applikationen dürfen nur eingeschränkte Zugriffsrechte auf die Hardware haben.
+
*[https://wiki.archlinux.org/title/KVM Arch Linux KVM Wiki]
−
*Gastsysteme dürfen keine Speicherbereiche sehen bzw. ändern können, die der Hypervisor zur Verwaltung benötigt.
+
*[[Einordnung der Virtualisierungssysteme]]
 +
*Animation: https://labs.xinux.net/hypervisor-schichten.html#swhw-3
  
−
=Protected Mode=
+
=Präsentation=
−
*Es gibt vier verschiedene als Ringe bezeichnete Schutzebenen bzw. Befugnisstufen
+
*https://hedgedoc.xinux.net/p/sC9T6-hrS#/
−
*Ablaufenden Codesegmenten wird unterschiedliche Rechte gewährt.
+
[[Kategorie:Virtualisierung]]
−
*Im Protected Mode läuft der Betriebssystem-Kernel in einem höher privilegierten Modus, der als Ring 0 bezeichnet wird
 
−
*Applikationen in einem weniger privilegierten Modus, in der Regel entweder Ring 1 oder Ring 3.
 
−
*Hypervisor bzw. das Hostbetriebssystem werden aufgrund ihrer privilegierten Stellung bei der Ressourcenverwaltung mit Ring-0-Berechtigung ausgeführt.
 
−
*Gastsysteme müssen, um den Schutz der Hypervisor-Ressourcen zu gewährleisten, folglich entweder auf Berechtigungslevel Ring 1 oder Ring 3 ausgeführt werden.
 
−
=Deprivilegierung=
 
−
*x86-Betriebssysteme sind so implementiert, dass sie von der Ring-0-Berechtigung ausgehen
 
−
*Um in einer Virtualisierungslösung zu funktionieren müssen zwei Features implementiert sein
 
−
*Ring-Deprivilegierung
 
−
**Sie sorgt dafür, dass das Gastsystem alle Befehle so ausführen kann, als hätte es Ring-0-Berechtigungen auf der Hardware
 
−
**Obwohl es durch die Virtualisierung weniger privilegierte Berechtigungen hat.
 
−
*Ring Aliasing
 
−
**Es sorgt dafür, dass das Gastsystem, wenn es eine Aktion ausführt, immer die Antwort erhält, die es erhalten würde, wenn der Befehl mit Ring-0-Berechtigungen ausgeführt worden wäre.
 
−
** Beispielsweise existiert ein Befehl zur Abfrage des Privilegierungslevels, der mit allen Berechtigungsleveln aufgerufen werden darf.
 
−
**Würde ein Gastsystem diesen Befehl ohne Ring Aliasing aufrufen, würde es Ring 1 oder 3 als Antwort erhalten, mit Ring Aliasing erhält es Ring 0
 
−
=Prozessor Erweiterungen=
 
−
==Intel-Virtualisierungstechnologie (VT-x)==
 
−
*Codenamen „Vanderpool“ geführt, stellt die schließlich „VT-x“ genannte Technologie Hardwareunterstützung für die Virtualisierung auf Intel-x86-Prozessoren bereit.
 
−
*Ring Aliasing
 
−
*Ring Deprevilegierung
 
−
*Neuerungen durch VT-x ist die Einführung eines weiteren, ausschließlich für die Virtualisierung gedachten Berechtigungskonzepts
 
−
*Es werden zwei neue Berechtigungslevels „VMX Root Operation“ und „VMX non Root Operation“ eingeführt.
 
−
*Der Hypervisor wird im „VMX Root Operation“ ausgeführt, VMs dagegen im „VMX non Root Operation“.
 
−
*In beiden Modi sind Ring-0 bis Ring-3 als Berechtigungen vorhanden
 
−
*Jedoch können Ring-0-Instruktionen, die im „VMX non Root Operation“ durch VMs ausgeführt werden, nun durch den Hypervisor im „VMX Root Operation“ gefangen werden
 
−
*Es handelt sich also um eine Implementierung des „trap-and-emulate“-Verfahrens.
 
−
*Damit ist das Problem der Deprivilegierung gelöst und muss nicht mehr über Binär-Translation softwareseitig implementiert werden.
 
−
==AMD-Virtualisierung (AMD-V)==
 
−
*AMD entwickelte die erste Generation von Befehlssatzerweiterungen für die Virtualisierungsunterstützung unter dem Namen „Pacifica“
 
−
*Ring Aliasing
 
−
*Ring Deprevilegierung
 
−
=Links=
 
−
*https://tuxthink.blogspot.com/2011/12/kvm-introduction.html
 

Aktuelle Version vom 11. Oktober 2026, 12:00 Uhr

Was ist x86-Virtualisierung?

  • Techniken, um mehrere Betriebssysteme gleichzeitig auf einem x86-Prozessor auszuführen.
  • Ein Hypervisor verteilt die physischen Ressourcen effizient und isoliert an die VMs.
  • Ziel: Das Gastbetriebssystem merkt keinen Unterschied zwischen virtueller und physischer Hardware.

Das Problem: Schutzringe

  • x86-Prozessoren kennen vier Schutzringe (Ring 0–3).
    • Das Betriebssystem läuft in Ring 0 und darf alles.
    • Anwendungen laufen in Ring 3 und dürfen wenig.
    • Ring 1 und 2 werden praktisch nicht genutzt.
  • Ein Gast-Kernel erwartet ebenfalls Ring 0. Den belegt aber schon der Host bzw. der Hypervisor.

Früher: Software-Virtualisierung (vor ca. 2006)

  • Keine Unterstützung durch den Prozessor.
  • Der Gast-Kernel läuft deprivilegiert, z. B. in Ring 1.
  • Der Hypervisor muss kritische Befehle abfangen und per Software nachbilden (Binary Translation, z. B. frühes VMware) oder der Gast-Kernel wird angepasst (Paravirtualisierung, z. B. frühes Xen).
  • Nachteil: hoher Overhead durch häufiges Abfangen.
  • Nicht verwechseln mit Emulation: Gast und Host haben hier dieselbe Plattform, die CPU wird nicht nachgebaut.

Heute: Hardware-Virtualisierung mit VT-x / AMD-V

  • Der Prozessor bekommt zwei Betriebsmodi:
    • VMX Root Mode („Ring -1“): Hier läuft der Hypervisor mit voller Kontrolle über die Hardware.
    • VMX Non-Root Mode: Hier laufen die VMs. Das ist der „Gastmodus“.
  • Innerhalb jedes Modus gibt es wieder die Ringe 0–3:
    • Das Gastbetriebssystem läuft in seinem eigenen Ring 0, die Anwendungen in Ring 3.
    • Der Gast muss dafür nicht angepasst werden.
  • Kritische Operationen im Non-Root Mode lösen automatisch einen Wechsel zum Hypervisor aus.

Ablauf: VM-Entry und VM-Exit

  • VM-Entry: Der Hypervisor wechselt in die VM (Root → Non-Root). Ab jetzt rechnet der Gast direkt auf der CPU.
  • VM-Exit: Bei privilegierten Befehlen oder Gerätezugriffen springt die CPU automatisch zurück zum Hypervisor (Non-Root → Root).
  • Der Hypervisor erledigt die Aufgabe und startet die VM mit dem nächsten VM-Entry wieder.
  • VMCS (Virtual Machine Control Structure): Pro VM speichert die CPU deren Zustand (Register, Speicherverwaltung) und den Zustand des Hypervisors. Dadurch geht der Wechsel schnell.
  • Speicher und I/O: Der Hypervisor trennt den Speicher der VMs voneinander. Mit EPT (Intel) bzw. NPT (AMD) übersetzt die CPU auch die Speicheradressen der VM selbst. Gerätezugriffe werden emuliert (z. B. durch QEMU) oder an echte Geräte weitergereicht.
Am Beispiel KVM
  • KVM ist der Hypervisor im VMX Root Mode, die VM läuft im Non-Root Mode.
  • QEMU emuliert die Geräte der VM. Gerätezugriffe landen per VM-Exit bei KVM und werden an QEMU weitergegeben.

Hardwareerweiterungen

  • Intel VT-x: CPU-Flag vmx
  • AMD-V (auch SVM): CPU-Flag svm
  • Beide arbeiten nach demselben Prinzip.
grep -m1 -owE 'vmx|svm' /proc/cpuinfo
  • Keine Ausgabe = im BIOS/UEFI abgeschaltet oder nicht vorhanden.

Praxis-Beispiele

  • KVM (Kernel-based Virtual Machine, Linux)
  • VMware vSphere (ESXi)
  • Microsoft Hyper-V
  • Citrix XenServer

Weiterführende Informationen

Präsentation

Abgerufen von „https://xinux.net/index.php?title=X86-Virtualisierung&oldid=73608“