Après un an de développement, l'hyperviseur gratuit Xen 4.17 est sorti. Des sociétés telles qu'Amazon, Arm, Bitdefender, Citrix, EPAM Systems et Xilinx (AMD) ont participé au développement de la nouvelle version. La génération des mises à jour pour la branche Xen 4.17 durera jusqu'au 12 juin 2024, et la publication des correctifs de vulnérabilités jusqu'au 12 décembre 2025.
Principaux changements dans Xen 4.17 :
- Une conformité partielle est assurée avec les exigences pour le développement de programmes sûrs et fiables en langage C, formulées dans les spécifications MISRA-C utilisées dans la création de systèmes critiques. Xen implémente officiellement 4 directives et 24 règles MISRA-C (sur 143 règles et 16 directives), et intègre également l'analyseur statique MISRA-C dans les processus d'assemblage, qui vérifie la conformité aux exigences des spécifications.
- Offre la possibilité de définir une configuration Xen statique pour les systèmes ARM, qui code en dur toutes les ressources nécessaires au démarrage des invités à l'avance. Toutes les ressources, telles que la mémoire partagée, les canaux de notification d'événements et l'espace de mémoire de l'hyperviseur, sont pré-allouées au démarrage de l'hyperviseur plutôt que dynamiquement, éliminant ainsi les pannes possibles dues à un manque de ressources pendant le fonctionnement.
- Pour les systèmes embarqués basés sur l'architecture ARM, une prise en charge expérimentale (aperçu technique) de la virtualisation des E/S à l'aide des protocoles VirtIO a été implémentée. Le transport virtio-mmio est utilisé pour échanger des données avec un périphérique d'E/S virtuel, ce qui garantit la compatibilité avec une large gamme de périphériques VirtIO. La prise en charge du frontend Linux, de la boîte à outils (libxl/xl), du mode dom0less et des backends exécutés dans l'espace utilisateur a été implémentée (les backends virtio-disk, virtio-net, i2c et gpio ont été testés).
- Prise en charge améliorée du mode dom0less, qui vous permet d'éviter de déployer l'environnement dom0 lors du démarrage des machines virtuelles à un stade précoce du démarrage du serveur. Il est possible de définir des pools CPU (CPUPOOL) au démarrage (via l'arborescence des périphériques), ce qui permet d'utiliser des pools dans des configurations sans dom0, par exemple, pour lier différents types de cœurs CPU sur les systèmes ARM basés sur le big.LITTLE architecture, combinant des cœurs puissants mais énergivores, et des cœurs moins productifs mais plus économes en énergie. De plus, dom0less offre la possibilité de lier le frontend/backend de paravirtualisation aux systèmes invités, ce qui vous permet de démarrer les systèmes invités avec les périphériques 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 permet une meilleure isolation entre les invités en cas de pannes liées à la mémoire.
- Pour les systèmes ARM, une protection contre la vulnérabilité Spectre-BHB dans les structures microarchitecturales des processeurs a été ajoutée.
- Sur les systèmes ARM, il est possible d'exécuter le système d'exploitation Zephyr dans l'environnement racine Dom0.
- La possibilité d'un assemblage d'hyperviseur séparé (hors arbre) est fournie.
- Sur les systèmes x86, les grandes pages IOMMU (superpage) sont prises en charge pour tous les types de systèmes invités, ce qui permet d'augmenter le débit lors du transfert de périphériques PCI. Ajout de la prise en charge des hôtes équipés de jusqu'à 12 To de RAM. Au stade du démarrage, la possibilité de définir les paramètres cpuid pour dom0 a été implémentée. Pour contrôler les mesures de protection mises en œuvre au niveau de l'hyperviseur contre les attaques sur le CPU dans les systèmes invités, les paramètres VIRT_SSBD et MSR_SPEC_CTRL sont proposés.
- Le transport VirtIO-Grant est développé séparément, se différenciant de VirtIO-MMIO par un niveau de sécurité plus élevé et la possibilité d'exécuter des gestionnaires dans un domaine isolé distinct pour les pilotes. VirtIO-Grant, au lieu du mappage direct de la mémoire, utilise la traduction des adresses physiques du système invité en liens d'autorisation, ce qui permet d'utiliser des zones de mémoire partagée préalablement convenues pour l'échange de données entre le système invité et le backend VirtIO, sans accorder d'autorisation. les droits du backend pour effectuer le mappage de la mémoire. Le support de VirtIO-Grant est déjà implémenté dans le noyau Linux, mais n'est pas encore inclus dans les backends QEMU, dans virtio-vhost et dans la boîte à outils (libxl/xl).
- L'initiative Hyperlaunch continue de se développer, visant à fournir des outils flexibles pour configurer le lancement des machines virtuelles lors du démarrage du système. Actuellement, le premier ensemble de correctifs a déjà été préparé pour vous permettre de détecter les domaines PV et de transférer leurs images vers l'hyperviseur lors du chargement. Tout le nécessaire pour exécuter de tels domaines paravirtualisés a également été implémenté, y compris les composants Xenstore pour les pilotes photovoltaïques. Une fois les correctifs acceptés, les travaux commenceront pour permettre la prise en charge des périphériques PVH et HVM, ainsi que la mise en œuvre d'un domaine domB distinct (domaine constructeur), adapté à l'organisation d'un démarrage mesuré, confirmant la validité de tous les composants chargés.
- Les travaux se poursuivent sur la création d'un portage de Xen pour l'architecture RISC-V.
Source: opennet.ru