Après un an de développement, la sortie de l'hyperviseur libre Xen 4.17 a été publiée. Des entreprises telles qu'Amazon, Arm, Bitdefender, Citrix, EPAM Systems et Xilinx (AMD) ont participé au développement de cette nouvelle version. La formation des mises à jour pour la branche Xen 4.17 se poursuivra jusqu'au 12 juin 2024, et la publication des correctifs de vulnérabilités jusqu'au 12 décembre 2025.
Modifications clés dans Xen 4.17 :
- Une conformité partielle aux exigences pour le développement de programmes sûrs et fiables en C, énoncées dans les spécifications MISRA-C, utilisées lors de la création de systèmes critiques, a été assurée. Quatre directives et 24 règles MISRA-C (sur un total de 143 règles et 16 directives) ont été officiellement intégrées dans Xen, et l'intégration d'un analyseur statique MISRA-C, vérifiant le respect des exigences de spécification, a été assurée dans les processus de construction.
- La possibilité de définir une configuration statique de Xen pour les systèmes ARM a été fournie, déterminant à l'avance toutes les ressources nécessaires au démarrage des systèmes invités. Toutes les ressources, telles que la mémoire partagée, les canaux de notification d'événements et l'espace mémoire pour l'hyperviseur, sont allouées à l'avance au démarrage de l'hyperviseur, plutôt que d'être allouées dynamiquement, ce qui élimine les éventuels pannes dues à un manque de ressources pendant l'exécution.
- Pour les systèmes embarqués basés sur l'architecture ARM, une prise en charge expérimentale (tech preview) de la virtualisation des entrées/sorties utilisant les protocoles VirtIO a été mise en place. Pour l'échange de données avec un périphérique d'entrée/sortie virtuel, le transport virtio-mmio a été utilisé, permettant la compatibilité avec un large éventail de périphériques VirtIO. Un support du frontend pour Linux, des outils (libxl/xl), du mode dom0less et des backends exécutés en espace utilisateur (les backends virtio-disk, virtio-net, i2c et gpio ont été testés) a été réalisé.
- Le support du mode dom0less, permettant de se passer du déploiement d'un environnement dom0 lors du démarrage, a été amélioré. machines virtuelles Lors du chargement initial du serveur, une fonctionnalité a été ajoutée pour définir des pools de CPU (CPUPOOL) au moment du démarrage (via l'arbre des dispositifs), permettant d'utiliser ces pools dans des configurations sans dom0, par exemple, pour attacher différents types de cœurs CPU sur des systèmes ARM basés sur l'architecture big.LITTLE, qui combinent dans une seule puce des cœurs puissants mais énergivores et des cœurs moins performants mais plus économes en énergie. De plus, dans les configurations sans dom0, il est possible d'attacher le frontend/backend de la paravirtualisation aux systèmes invités, permettant de démarrer ces systèmes avec les dispositifs paravirtualisés nécessaires.
- Sur les systèmes ARM, les structures de virtualisation de la mémoire (P2M, Physical to Machine) sont désormais allouées à partir du pool de mémoire créé lors de la création du domaine, ce qui améliore l'efficacité de l'isolation entre les systèmes invités en cas d'erreurs liées à la mémoire.
- Pour les systèmes ARM, une protection contre la vulnérabilité Spectre-BHB a été ajoutée dans les structures microarchitecturales des processeurs.
- Sur les systèmes ARM, il est désormais possible d'exécuter le système d'exploitation Zephyr dans l'environnement racine Dom0.
- Il est désormais possible de compiler le hyperviseur séparément (out-of-tree).
- Sur les systèmes x86, un support pour les pages IOMMU de grande taille (superpage) a été assuré pour tous les types de systèmes invités, ce qui augmente la bande passante lors du passage des périphériques PCI. Un soutien a été ajouté pour les hôtes équipés de jusqu'à 12 To de RAM. Lors du démarrage, il est possible de définir des paramètres cpuid pour dom0. Pour gérer les mesures de protection contre les attaques sur CPU mises en œuvre dans les systèmes invités au niveau de l'hyperviseur, des paramètres VIRT_SSBD et MSR_SPEC_CTRL sont proposés.
- Le transport VirtIO-Grant est en développement, caractérisé par un niveau de sécurité supérieur par rapport à VirtIO-MMIO et par la possibilité d'exécuter des gestionnaires dans un domaine isolé séparé pour les pilotes. Dans VirtIO-Grant, au lieu d'un mappage direct de la mémoire, une translation des adresses physiques du système invité en références de grant est utilisée, permettant l'utilisation de zones de mémoire partagée pré-approuvées pour l'échange de données entre le système invité et le backend VirtIO, sans donner au backend le droit d'effectuer des mappages de mémoire. La prise en charge de VirtIO-Grant a déjà été mise en œuvre dans le noyau Linux, mais n'est pas encore incluse dans les backends QEMU, dans virtio-vhost et dans l'outil (libxl/xl).
- Le développement de l'initiative Hyperlaunch se poursuit, visant à fournir des outils flexibles pour configurer le démarrage des machines virtuelles lors du chargement du système. Actuellement, un premier ensemble de correctifs est prêt, permettant de définir les domaines PV et de transmettre leurs images au chargeur d'hyperviseur. Tout le nécessaire pour lancer de tels environnements paravirtualisés a également été mis en œuvre. domaines, y compris les composants Xenstore pour les pilotes PV. Une fois les correctifs acceptés, le travail commencera pour inclure le support des dispositifs PVH et HVM, ainsi que la mise en œuvre d'un domaine distinct domB (domaine constructeur), adapté pour organiser un démarrage mesuré (measured boot), certifiant l'authenticité de tous les composants chargés.
- Le travail sur la création d'un port Xen pour l'architecture RISC-V se poursuit.
Source : opennet.ru
