Nach einem Jahr der Entwicklung wurde die Version 4.17 des freien Hypervisors Xen veröffentlicht. An der Entwicklung der neuen Version waren Unternehmen wie Amazon, Arm, Bitdefender, Citrix, EPAM Systems und Xilinx (AMD) beteiligt. Die Entwicklung von Updates für den Xen-Zweig 4.17 wird 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 Konformität mit den Anforderungen zur Entwicklung sicherer und zuverlässiger Software in C, die in den MISRA-C-Spezifikationen festgelegt sind und bei der Erstellung kritischer Systeme angewendet werden, gewährleistet. In Xen wurden offiziell 4 Direktiven und 24 Regeln von MISRA-C (von insgesamt 143 Regeln und 16 Direktiven) eingeführt, und die Integration des statischen Analysewerkzeugs MISRA-C in die Build-Prozesse zur Überprüfung der Einhaltung der Spezifikationen wurde sichergestellt.
- Die Möglichkeit, die statische Konfiguration von Xen für ARM-Systeme festzulegen, wurde bereitgestellt, die alle Ressourcen vordefiniert, die für das Laden von Gastsystemen erforderlich sind. Alle Ressourcen, wie gemeinsam genutzter Speicher, Benachrichtigungskanäle für Ereignisse und Heap-Speicher des Hypervisors, werden bereits beim Starten des Hypervisors vorab zugewiesen und nicht dynamisch verteilt, was potenzielle Ausfälle aufgrund von Ressourcenmangel während des Betriebs ausschließt.
- Für eingebettete Systeme basierend auf der ARM-Architektur wurde experimentelle (tech preview) Unterstützung für die Virtualisierung von Ein- und Ausgabe unter Verwendung der VirtIO-Protokolle implementiert. Für den Datenaustausch mit dem virtuellen Ein-/Ausgabegerät wird der Transport virtio-mmio verwendet, was die Kompatibilität mit einer Vielzahl von VirtIO-Geräten ermöglicht. Unterstützung wurde für das Frontend unter Linux, das Toolkit (libxl/xl), den dom0less-Modus und Benutzermodus-Backends implementiert (getestet wurden die Backends virtio-disk, virtio-net, i2c und gpio).
- Die Unterstützung des dom0less-Modus wurde verbessert, der eine Bereitstellung der dom0-Umgebung beim Serverstart überflüssig macht. virtuelle Maschinen In der frühen Phase des Serverstarts wurde die Möglichkeit eingeführt, CPU-Pools (CPUPOOL) während des Starts (über den Gerätestrang) zu definieren, was die Nutzung dieser Pools in Konfigurationen ohne dom0 ermöglicht. Dies ist beispielsweise nützlich zur Bindung verschiedener CPU-Kernarten in ARM-Systemen, die auf der big.LITTLE-Architektur basieren, welche leistungsstarke, aber energieintensive Kerne mit weniger leistungsstarken, aber energieeffizienten Kernen kombiniert. Darüber hinaus wurde in dom0less die Möglichkeit geschaffen, Frontend/Backend der Paravirtualisierung an Gastsysteme zu binden, was das Booten von Gastsystemen mit den erforderlichen paravirtualisierten Geräten ermöglicht.
- In ARM-Systemen werden die Speicher-Virtualisierungsstrukturen (P2M, Physical to Machine) nun aus dem Speicherpool zugewiesen, der bei der Erstellung des Domains gebildet wird. Dies erhöht die Effizienz der Isolation zwischen den Gastsystemen, insbesondere bei speicherbezogenen Fehlern.
- ARM-Systemen wurde der Schutz vor der Spectre-BHB-Sicherheitsanfälligkeit in den Mikroarchitekturstrukturen der Prozessoren hinzugefügt.
- ARM-Systemen ermöglicht es, das Betriebssystem Zephyr in der Root-Umgebung von Dom0 zu starten.
- Die Möglichkeit zur separaten (out-of-tree) Erstellung des Hypervisors wurde bereitgestellt.
- x86-Systemen wird die Unterstützung für große IOMMU-Seiten (Superpage) für alle Typen von Gastsystemen geboten, was die Bandbreite beim Durchleiten von PCI-Geräten erhöht. Die Unterstützung von Hosts mit bis zu 12 TB RAM wurde hinzugefügt. Erstmals können beim Booten cpuid-Parameter für dom0 festgelegt werden. Für den Hypervisor implementierte Schutzmaßnahmen gegen CPU-Angriffe wurden durch die Parameter VIRT_SSBD und MSR_SPEC_CTRL angeboten.
- Die VirtIO-Grant-Transporttechnologie wird separat entwickelt und bietet ein höheres Sicherheitsniveau als VirtIO-MMIO sowie die Möglichkeit, Handler in einer isolierten Domäne für Treiber auszuführen. Bei VirtIO-Grant wird anstelle einer direkten Mappierung von Speicher die Umwandlung physischer Adressen des Gastsystems in Grant-Referenzen verwendet, was geregelt Bereiche des gemeinsamen Speichers für den Datenaustausch zwischen dem Gastsystem und dem VirtIO-Backend ermöglicht, ohne dem Backend das Recht zu gewähren, den Speicher zu mappen. Die Unterstützung von VirtIO-Grant ist bereits im Linux-Kernel implementiert, jedoch noch nicht in den QEMU-Backends, virtio-vhost und den Tools (libxl/xl).
- Die Entwicklung der Hyperlaunch-Initiative, die darauf abzielt, flexible Werkzeuge für die Konfiguration des Starts virtueller Maschinen während des Systemstarts bereitzustellen, geht weiter. Der erste Satz von Patches, der es ermöglicht, PV-Domänen zu identifizieren und deren Images beim Booten an den Hypervisor zu übergeben, ist bereits fertiggestellt. Auch alles Notwendige für den Start solcher para-virtualisierten Umgebungen wurde umgesetzt. Domains, einschließlich der Xenstore-Komponenten für PV-Treiber. Nach der Annahme der Patches wird die Unterstützung für PVH- und HVM-Geräte in Angriff genommen, ebenso wie die Implementierung einer separaten Domäne domB (Builder-Domäne), die für die Organisation eines gemessenen Starts (measured boot) geeignet ist, der die Integrität aller geladenen Komponenten bestätigt.
- Die Arbeit an der Erstellung des Xen-Ports für die RISC-V-Architektur geht weiter.
Quelle: opennet.ru
