Nach einem Jahr Entwicklung wurde die Veröffentlichung des freien Hypervisors Xen 4.17 bekannt gegeben. An der Entwicklung dieser neuen Version waren Unternehmen wie Amazon, Arm, Bitdefender, Citrix, EPAM Systems und Xilinx (AMD) beteiligt. Die Aktualisierungen für die Version Xen 4.17 werden bis zum 12. Juni 2024 fortgesetzt, während die Veröffentlichung von Sicherheitsupdates bis zum 12. Dezember 2025 geplant ist.
Wesentliche Änderungen in Xen 4.17:
- Es wurde eine teilweise Übereinstimmung mit den Anforderungen an die Entwicklung sicherer und zuverlässiger Software in C, die in den MISRA-C-Spezifikationen formuliert sind und bei der Entwicklung kritischer Systeme Anwendung finden, sichergestellt. In Xen wurden offiziell 4 Direktiven und 24 Regeln von MISRA-C (aus insgesamt 143 Regeln und 16 Direktiven) implementiert, sowie die Integration in die Build-Prozesse des statischen Analysators von MISRA-C, der die Einhaltung der Spezifikationsanforderungen überprüft.
- Es besteht die Möglichkeit, eine statische Xen-Konfiguration für ARM-Systeme festzulegen, die im Voraus alle Ressourcen definiert, die für das Booten der Gastsysteme erforderlich sind. Alle Ressourcen wie gemeinsamer Speicher, Benachrichtigungskanäle und Speicherplatz im Hypervisor-Heap werden bereits beim Start des Hypervisors zugewiesen, anstatt dynamisch zugeteilt zu werden, wodurch mögliche Ausfälle aufgrund von Ressourcenengpässen während des Betriebs ausgeschlossen werden.
- Für eingebettete Systeme auf Basis der ARM-Architektur wurde eine experimentelle (Tech Preview) Unterstützung für die Virtualisierung von Ein- und Ausgabeverfahren unter Verwendung von VirtIO-Protokollen implementiert. Der Datenaustausch mit dem virtuellen Ein-/Ausgabegerät erfolgt über den Transport virtio-mmio, was die Kompatibilität mit einer Vielzahl von VirtIO-Geräten ermöglicht. Zudem wurde eine Unterstützung für das Frontend unter Linux, das Toolset (libxl/xl), den Dom0less-Modus und Benutzerraum-Backends implementiert (getestet wurden Backends wie virtio-disk, virtio-net, I2C und GPIO).
- Die Unterstützung des dom0less-Modus wurde verbessert, was das Starten des Servers ohne das Bereitstellen einer dom0-Umgebung ermöglicht. virtuellen Maschinen Während der anfänglichen Server-Bootphase wurde die Möglichkeit zur Definition von CPU-Pools (CPUPOOL) über den Device Tree eingeführt, was die Verwendung dieser Pools in Konfigurationen ohne dom0 ermöglicht. Dies ist besonders nützlich für die Zuweisung verschiedener CPU-Kern-Typen in ARM-Systemen, die auf der big.LITTLE-Architektur basieren, die leistungsstarke, aber energieintensive Kerne mit weniger leistungsstarken, dafür energieeffizienten Kernen kombiniert. Außerdem kann in dom0less-Umgebungen der Frontend-/Backend-Bereich der Paravirtualisierung mit den Gastsystemen verknüpft werden, was das Booten der Gastsysteme mit den erforderlichen paravirtualisierten Geräten ermöglicht.
- Auf ARM-Systemen werden die Strukturen der Speichervirtualisierung (P2M, Physical to Machine) nun aus einem Maschinentypen-Pool zugewiesen, der während der Erstellung des Domänen gebildet wird. Dadurch wird die Effizienz der Isolation zwischen den Gastsystemen verbessert, insbesondere wenn speicherbezogene Fehler auftreten.
- Für ARM-Systeme wurde ein Schutz gegen die Spectre-BHB-Sicherheitsanfälligkeit in den mikroarchitektonischen Strukturen der Prozessoren hinzugefügt.
- Auf ARM-Systemen besteht die Möglichkeit, das Betriebssystem Zephyr in der Root-Umgebung von Dom0 zu starten.
- Die Möglichkeit einer separaten (out-of-tree) Hypervisor-Kompilierung wurde bereitgestellt.
- Auf x86-Systemen wird die Unterstützung großer IOMMU-Seiten (Superpage) für alle Arten von Gastsystemen gewährleistet, was die Bandbreite beim Durchreichen von PCI-Geräten erhöht. Unterstützung für Hosts mit bis zu 12 TB RAM wurde hinzugefügt. Beim Bootvorgang besteht die Möglichkeit, die cpuid-Parameter für dom0 festzulegen. Für den Schutz vor CPU-Angriffen in den Gastsystemen, die auf Hypervisorebene implementiert sind, wurden die Parameter VIRT_SSBD und MSR_SPEC_CTRL angeboten.
- Der VirtIO-Grant-Treiber entwickelt sich unabhängig und bietet im Vergleich zu VirtIO-MMIO ein höheres Maß an Sicherheit sowie die Möglichkeit, Handler in einer isolierten Domäne für Treiber auszuführen. Bei VirtIO-Grant erfolgt anstelle der direkten Speicherzuordnung eine Übersetzung der physischen Adressen des Gastes in Grant-Referenzen. Dies ermöglicht die Verwendung von zuvor genehmigten Bereichen des gemeinsamen Speichers für den Datenaustausch zwischen dem Gastbetriebssystem und dem VirtIO-Backend, ohne dass dem Backend das Recht zur Speicherzuordnung eingeräumt wird. Die Unterstützung von VirtIO-Grant ist bereits im Linux-Kernel implementiert, jedoch derzeit noch nicht in den QEMU-Backends, in virtio-vhost und in den Tools (libxl/xl).
- Die Initiative Hyperlaunch wird weiterhin vorangetrieben, um flexible Werkzeuge zur Konfiguration des Starts virtueller Maschinen während des Systemstarts bereitzustellen. Der erste Satz von Patches ist bereits fertiggestellt und ermöglicht die Definition von PV-Domänen sowie die Übertragung ihrer Images beim Booten des Hypervisors. Außerdem wurden alle notwendigen Vorkehrungen für den Start solcher paravirtuellen Umgebungen umgesetzt. Domänen, einschließlich der Xenstore-Komponenten für PV-Treiber. Nach der Annahme der Patches wird die Arbeit an der Unterstützung von PVH- und HVM-Geräten sowie der Implementierung einer separaten Domäne domB (builder domain) beginnen, die für die Durchführung eines messbaren Bootvorgangs (measured boot) geeignet ist und die Integrität aller geladenen Komponenten bestätigt.
- Die Entwicklung eines Xen-Ports für die RISC-V-Architektur geht weiter.
Quelle: opennet.ru
