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
