Xen-Hypervisor 4.17-Version

Nach einem Jahr Entwicklungszeit ist der kostenlose Hypervisor Xen 4.17 erschienen. An der Entwicklung des neuen Release waren Unternehmen wie Amazon, Arm, Bitdefender, Citrix, EPAM Systems und Xilinx (AMD) beteiligt. Die Generierung von Updates für den Xen 4.17-Zweig dauert bis zum 12. Juni 2024 und die Veröffentlichung von Schwachstellenkorrekturen bis zum 12. Dezember 2025.

Wichtige Änderungen in Xen 4.17:

  • Die Anforderungen für die Entwicklung sicherer und zuverlässiger Programme in der C-Sprache, formuliert in den MISRA-C-Spezifikationen, die bei der Erstellung geschäftskritischer Systeme verwendet werden, werden teilweise eingehalten. Xen implementiert offiziell 4 Richtlinien und 24 MISRA-C-Regeln (von 143 Regeln und 16 Richtlinien) und integriert außerdem den statischen MISRA-C-Analysator in Montageprozesse, der die Einhaltung der Spezifikationsanforderungen überprüft.
  • Bietet die Möglichkeit, eine statische Xen-Konfiguration für ARM-Systeme zu definieren, die alle zum Booten von Gästen erforderlichen Ressourcen im Voraus fest codiert. Alle Ressourcen, wie z. B. gemeinsam genutzter Speicher, Ereignisbenachrichtigungskanäle und Hypervisor-Heap-Speicherplatz, werden beim Start des Hypervisors vorab zugewiesen und nicht dynamisch zugewiesen, wodurch mögliche Ausfälle aufgrund von Ressourcenknappheit während des Betriebs vermieden werden.
  • Für eingebettete Systeme, die auf der ARM-Architektur basieren, wurde experimentelle (Tech Preview) Unterstützung für I/O-Virtualisierung mithilfe von VirtIO-Protokollen implementiert. Der virtio-mmio-Transport wird zum Datenaustausch mit einem virtuellen I/O-Gerät verwendet, wodurch die Kompatibilität mit einer Vielzahl von VirtIO-Geräten gewährleistet ist. Unterstützung für Linux-Frontend, Toolkit (libxl/xl), dom0less-Modus und Backends, die im Benutzerbereich ausgeführt werden, wurde implementiert (Virtio-Disk-, Virtio-Net-, i2c- und GPIO-Backends wurden getestet).
  • Verbesserte Unterstützung für den dom0less-Modus, der es Ihnen ermöglicht, die Bereitstellung der dom0-Umgebung zu vermeiden, wenn Sie virtuelle Maschinen in einem frühen Stadium des Serverstarts starten. Es ist möglich, CPU-Pools (CPUPOOL) in der Startphase (über den Gerätebaum) zu definieren, wodurch Sie Pools in Konfigurationen ohne dom0 verwenden können, um beispielsweise verschiedene Arten von CPU-Kernen auf ARM-Systemen basierend auf big.LITTLE zu binden Architektur, die leistungsstarke, aber energieverbrauchende Kerne mit weniger produktiven, aber energieeffizienteren Kernen kombiniert. Darüber hinaus bietet dom0less die Möglichkeit, Paravirtualisierungs-Frontend/Backend an Gastsysteme zu binden, wodurch Sie Gastsysteme mit den erforderlichen paravirtualisierten Geräten starten können.
  • Auf ARM-Systemen werden Speichervirtualisierungsstrukturen (P2M, Physical to Machine) jetzt aus dem beim Erstellen der Domäne erstellten Speicherpool zugewiesen, was eine bessere Isolierung zwischen Gästen ermöglicht, wenn speicherbezogene Ausfälle auftreten.
  • Für ARM-Systeme wurde ein Schutz vor der Spectre-BHB-Schwachstelle in Prozessor-Mikroarchitekturstrukturen hinzugefügt.
  • Auf ARM-Systemen ist es möglich, das Zephyr-Betriebssystem in der Dom0-Root-Umgebung auszuführen.
  • Es besteht die Möglichkeit einer separaten (out-of-tree) Hypervisor-Assembly.
  • Auf x86-Systemen werden große IOMMU-Seiten (Superpage) für alle Arten von Gastsystemen unterstützt, was eine Erhöhung des Durchsatzes bei der Weiterleitung von PCI-Geräten ermöglicht. Unterstützung für Hosts mit bis zu 12 TB RAM hinzugefügt. In der Boot-Phase wurde die Möglichkeit implementiert, CPU-ID-Parameter für dom0 festzulegen. Zur Steuerung der auf Hypervisor-Ebene implementierten Schutzmaßnahmen gegen Angriffe auf die CPU in Gastsystemen werden die Parameter VIRT_SSBD und MSR_SPEC_CTRL vorgeschlagen.
  • Der VirtIO-Grant-Transport wird separat entwickelt und unterscheidet sich von VirtIO-MMIO durch ein höheres Maß an Sicherheit und die Möglichkeit, Handler in einer separaten isolierten Domäne für Treiber auszuführen. VirtIO-Grant verwendet anstelle der direkten Speicherzuordnung die Übersetzung physischer Adressen des Gastsystems in Grant-Links, was die Nutzung vorab vereinbarter Bereiche des gemeinsam genutzten Speichers für den Datenaustausch zwischen dem Gastsystem und dem VirtIO-Backend ohne Gewährung ermöglicht die Backend-Rechte zur Durchführung der Speicherzuordnung. Die VirtIO-Grant-Unterstützung ist bereits im Linux-Kernel implementiert, jedoch noch nicht in den QEMU-Backends, in virtio-vhost und im Toolkit (libxl/xl) enthalten.
  • Die Hyperlaunch-Initiative entwickelt sich weiter und zielt darauf ab, flexible Tools zum Konfigurieren des Starts virtueller Maschinen während des Systemstarts bereitzustellen. Derzeit sind bereits die ersten Patches vorbereitet, mit denen Sie PV-Domänen erkennen und deren Bilder beim Laden an den Hypervisor übertragen können. Außerdem wurde alles Notwendige zum Betrieb solcher paravirtualisierten Domänen implementiert, einschließlich Xenstore-Komponenten für PV-Treiber. Sobald die Patches akzeptiert sind, beginnen die Arbeiten zur Aktivierung der Unterstützung für PVH- und HVM-Geräte sowie zur Implementierung einer separaten domB-Domäne (Builder-Domäne), die für die Organisation eines gemessenen Starts geeignet ist und die Gültigkeit aller geladenen Komponenten bestätigt.
  • Die Arbeit an der Erstellung eines Xen-Ports für die RISC-V-Architektur geht weiter.

Source: opennet.ru

Kommentar hinzufügen