Seite 4: Virtualisierung

Inhaltsverzeichnis

Gasttreiber für VirtualBox jetzt im Lieferumfang

Dank des "Virtual Box Guest integration support" braucht man in Zukunft einen Kernel-Treiber weniger installieren und pflegen, wenn man Linux als Gast unter VirtualBox betreibt. Das ist dem Treiber Vboxguest zu verdanken, den ein Red-Hat-Entwickler in den Kernel eingebracht hat, um die Out-of-the-box-Unterstützung für Oracles Virtualisierungslösung zu verbessern. Der Treiber ermöglicht neben Copy & Paste zwischen Host und Gast auch ein Durchreichen von OpenGL-Befehlen; damit kann man die 3D-Beschleunigung der Host-Grafikkarte in VMs nutzen. Der Treiber stellt auch Funktionen für den Seamless-Mode, bei dem einzelne Anwendungsfenster des Gastsystems als autarke Fenster in der Bedienoberfläche des Hosts erscheinen. Damit diese Features arbeiten, muss die im Gast laufendeLinux-Distribution auch die quelloffenen Userspace-Treiber mitbringen, die über den neuen Kernel-Treiber (1, 2, 3) mit dem Host kommunizieren.

Der Entwickler, der die Integration vorangetrieben hat, hatte bei Linux 4.13 schon den Grafiktreiber Vboxvideo eingebracht, der die von VirtualBox emulierte GPU unterstützt. Dieser liegt allerdings nach wie vor im Staging-Bereich, wo Programmierer versuchen, Code auf Vordermann zu bringen, der die Qualitäts- oder Pflegeansprüche der Kernel-Entwickler bekanntermaßen nicht erfüllt. An der Integration des Treiber Vboxsf, mit dem sich Verzeichnisse des Hosts in Gastsysteme einbinden lassen, arbeitet der Entwickler noch. Letztlich erleichtert die Integration der Gasttreiber aber schon jetzt den Einsatz in VirtualBox deutlich: Wer die Shared-Folder-Funktion nicht benötigt, braucht im Gast jetzt keine Kernel-Module mehr zu kompilieren. Das spart Zeit und vermeidet einige Stolperfallen beim Bau solcher Module, die gerade Linux-Novizen bei ihren ersten Gehversuchen zu Fall bringen.

VMs mit individueller Speicherverschlüsselung

Der Kernel-eigene Hypervisor KVM kann jetzt die Speicherverschlüsselung nutzen, mit der einige aktuelle AMD-Prozessoren den Arbeitsspeicher von Virtual Machines (VMs) individuell verschlüsseln können (u. a. 1, 2, 3, 4, Dokumentation). Das verspricht mehr Sicherheit in Zeiten von Meltdown und Spectre: In einer VM agierende Angreifer erreichen allenfalls  verschlüsselte Speicherinhalte von Host und anderen VMs, wenn sie Sicherheitslücken in Hardware oder Virtualisierungslösung kennen, über die sie sie den gesamten Arbeitsspeicher auslesen können. Das ist vor allem für Cloud-Provider und deren Kunden interessant, bei denen VMs unterschiedlicher Kunden parallel auf einem System laufen. Außerdem sind Kundendaten so auch vor den Mitarbeitern der Cloud-Provider geschützt, denn durch das Ganze kommen auch Admins des Hosts nicht an Speicherinhalte des Gastes. Naturgemäß gilt das alles natürlich nur, solange AMDs Verschlüsselungsfunktion wie dokumentiert arbeitet und selbst keine Lücken aufweist.

Die Verschlüsselungsfunktion in KVM fußt auf der Unterstützung für die AMD-Techniken "Secure Memory Encryption" (SME) und "Secure Encrypted Virtualization" (SEV), die bei Linux 4.14 respektive Linux 4.15 dazustießen und seinerzeit im Kernel-Log schon näher erläutert wurden. Um die von Epyc- und Ryzen-Pro-CPUs unterstützte Technik verwenden zu können, muss allerdings auch die Software angepasst werden, die mit KVM virtualisiert. In der Regel ist das Qemu, das die Speicherverschlüsselung durch einige von AMD vorangetriebene Patches lernen soll. Ferner müssen dann auch noch Bibliotheken wie Libvirt angepasst werden, damit darauf aufbauende Software wie Virt-Manager oder Gnome Boxes das Ganze auch anbieten.

Support für Hardware-Partitionierung mit Jailhouse

Der x86-Code von Linux bringt nun alles mit, um als Gastsystem in einer "non root cell" von Jailhouse zu laufen. Dieser maßgeblich von deutschen Siemens-Entwicklern vorangetriebene Hypervisor geht Virtualisierung anders an als KVM, Xen & Co.: Er partitioniert die Hardware in "Zellen", die volle Kontrolle über CPU-Kerne, Arbeitsspeicherbereiche und andere Hardware-Ressourcen erhalten, die ihnen zugeteilt wurden. Das vermeidet den bei klassischer x86-Virtualisierung immanenten Wettbewerb, durch den VMs und Prozesse des Hosts um CPU-Zeit und andere Hardware-Ressourcen konkurrieren.

Die statische Partitionierung der Hardware von Jailhouse isoliert Gäste somit viel besser, was für bestimmte Echtzeit- und Sicherheitsanwendungen interessant oder Voraussetzung ist. Naturgemäß gelingt mit Jailhouse kein Overcommitment, bei der die Summe der VMs zugeteilten Hardware-Ressourcen die tatsächlich vorhandenen Ressourcen übersteigt; dieser Trick kommt häufiger bei der Virtualisierung mit KVM, Xen & Co. zum Einsatz, um das Leistungspotenzial der Hardware besser auszuschöpfen.

Jailhouse ist auf Virtualisierungsfunktionen in der CPU angewiesen und unterstützt ARMv7-, ARMv8- und x86-64-Prozessoren. Jailhouse arbeitet autark, bootet aber mit Hilfe von Linux, das der Hypervisor bei seiner Initialisierung in die "root cell" hievt; dies Linux verliert dann die Kontrolle über Hardware-Ressourcen, die VMs zugeteilt werden.

Performance-Verbesserungen für KVM und Hyper-V

Der neue "Paravirtualized TLB Flush" im KVM-Code verspricht einen Geschwindigkeitsgewinn auf Hosts, indem er den VMs mehr CPU-Kerne zuteilt, als tatsächlich im System stecken (Overcommitment).

Einige weitere Änderungen an KVM nennt der Merge Commit, der die wesentlichsten Änderungen am Kernel-eigenen Hypervisor gebracht hat. Beim Xen-Support gab es diesmal nur Detailverbesserungen.

Linux kann beim Gastbetrieb unter Microsofts Hyper-V jetzt Process-Context Identifiers (PCID) nutzen. Das kann die Geschwindigkeitseinbußen der Meltdown-Gegenmaßnahme PTI (Page Table Isolation) erheblich reduzieren. Damit das gelingt, muss der Hypervisor diese Prozessor-Funktion aber auch zur Nutzung durch Gäste freigeben.