Xen est un hyperviseur qui fournit une isolation sécurisée, un contrôle des ressources, des garanties de qualité de service et la migration des machines virtuelles.
Après un an de développement, le lancement de la nouvelle version de l'hyperviseur gratuit Xen 4.17, version dans laquelle la formation de mises à jour pour la branche Xen 4.17 durera jusqu'au 12 juin 2024 et la publication de correctifs de vulnérabilité jusqu'au 12 décembre 2025.
Il convient de mentionner que des sociétés telles qu'Amazon, Arm, Bitdefender, Citrix, EPAM Systems et Xilinx (AMD) ont contribué au développement de la nouvelle version.
Xen 4.17 Principales nouvelles fonctionnalités
Dans cette nouvelle version qui est présentée, il est mis en évidence que le possibilité de définir une configuration Xen statique pour les systèmes ARM qui encode à l'avance toutes les ressources nécessaires au démarrage des systèmes invités. toutes les ressourcestels que la mémoire partagée, les canaux de notification d'événements et l'espace de stockage de l'hyperviseur, sont pré-alloués au démarrage de l'hyperviseur au lieu d'être alloués dynamiquement, ce qui élimine la possibilité d'échec dû au manque de ressources.
Pour systèmes embarqués basés sur l'architecture ARM, a été mis en place support expérimental (aperçu technique) Pour la virtualisation d'E/S utilisant les protocoles VirtIO, virtio-mmio est utilisé pour communiquer avec le périphérique d'E/S virtuel, ce qui nous a permis d'assurer la compatibilité avec une large gamme de périphériques VirtIO. On retrouve également la compatibilité implémentée pour le frontend Linux, avec libxl/xl, le mode dom0less et les backends userspace.
Un autre des changements qui se démarque est la prise en charge améliorée du mode dom0less, qui permet d'éviter d'implémenter un environnement dom0 lors du démarrage de machines virtuelles à un stade précoce du démarrage du serveur.
le possibilité de définir des groupes de CPU (CPUPOOL) au démarrage (via l'arborescence des périphériques), qui permet d'utiliser des groupes dans des configurations sans dom0, par exemple, pour relier différents types de cœurs de processeur dans des systèmes ARM basés sur l'architecture big.LITTLE, qui combine des cœurs puissants, mais gourmands en énergie, 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 invités, ce qui vous permet de démarrer les invités avec les appareils paravirtualisés nécessaires.
Dans les systèmes ARM, structures de virtualisation de la mémoire (P2M, physique à machine) maintenant sont alloués à partir du pool de mémoire créé lors de la création d'un domaine, permettant une meilleure isolation entre les invités lorsque des pannes liées à la mémoire se produisent.
Dans les systèmes x86, les pages IOMMU sont prises en charge (superpage) pour tous les types de systèmes invités, permettant des performances accrues lors du transfert de périphériques, PCI, plus prise en charge supplémentaire des hôtes avec jusqu'à 12 To de RAM. Au stade du démarrage, la possibilité de définir des paramètres cpuid pour dom0 est implémentée. Les paramètres VIRT_SSBD et MSR_SPEC_CTRL sont proposés pour contrôler la protection au niveau de l'hyperviseur contre les attaques CPU sur les systèmes invités.
De l' autres changements qui se démarquent:
- Protection supplémentaire contre la vulnérabilité Spectre-BHB dans les structures de microarchitecture de processeur pour les systèmes ARM.
- Sur les systèmes ARM, la possibilité d'exécuter le système d'exploitation Zephyr dans l'environnement racine Dom0 est fournie.
La possibilité d'un assemblage d'hyperviseur séparé (en dehors de l'arborescence) est fournie.
Séparément, le transport VirtIO-Grant est en cours de développement, qui diffère de VirtIO-MMIO par un niveau de sécurité plus élevé et la possibilité d'exécuter des contrôleurs dans un domaine isolé séparé pour les contrôleurs.
Au lieu d'un mappage direct de la mémoire, VirtIO-Grant utilise la traduction des adresses physiques de l'invité en liens de location, permettant l'utilisation de zones de mémoire partagée pré-convenues pour l'échange de données entre l'invité et le backend VirtIO, sans accorder au backend le droit de effectuer le mappage de la mémoire. La prise en charge de VirtIO-Grant est déjà implémentée dans le noyau Linux, mais n'est pas encore incluse dans les backends QEMU, virtio-vhost et toolkit (libxl/xl).
L'initiative Hyperlaunch continue de se développer pour fournir des outils flexibles permettant de personnaliser le lancement des machines virtuelles au démarrage du système. Actuellement, le premier ensemble de correctifs est prêt, permettant de définir des domaines PV et de transférer leurs images vers l'hyperviseur lors du téléchargement. toi
Enfin Si cela vous intéresse d'en savoir plus, vous pouvez consulter les détails dans le lien suivant.