Après huit mois de développement la nouvelle version de l'hyperviseur gratuit Xen 4.15 vient de sortir et dans cette nouvelle version les mises à jour de la branche Xen 4.15 durera jusqu'au 8 octobre 2022 et la publication de correctifs de vulnérabilité jusqu'au 8 avril 2024.
Pour ceux qui ne connaissent pas Xen, sachez que est un moniteur de machine virtuelle open source développé par l'Université de Cambridge. L'objectif de la conception est de pouvoir exécuter des instances entièrement fonctionnelles de systèmes d'exploitation de manière entièrement fonctionnelle sur un seul ordinateur.
Xen fournit une isolation sécurisée, un contrôle des ressources, garantie de qualité de service et migration de machine virtuelle à chaud. Les systèmes d'exploitation peuvent être explicitement modifiés pour exécuter Xen (tout en maintenant la compatibilité avec les applications utilisateur).
Principales nouvelles fonctionnalités de Xen 4.15
Dans cette nouvelle version dans les processus Xenstored et Oxenstored ont ajouté un support expérimental pour les mises à jour en direct, permettant la livraison et l'application des correctifs de vulnérabilité sans redémarrer l'environnement hôte, plus ajout de la prise en charge des images de démarrage unifiées, vous permettant de créer des images système qui incluent des composants Xen. Ces images sont emballés sous la forme d'un binaire EFI unique qui peut être utilisé pour démarrer un système Xen en cours d'exécution directement à partir d'un gestionnaire de démarrage EFI sans chargeur de démarrage intermédiaire comme GRUB. L'image comprend des composants Xen tels que l'hyperviseur, le noyau pour l'environnement hôte (dom0), initrd, Xen KConfig, la configuration XSM et l'arborescence des périphériques.
Pour plateforme ARM, une possibilité expérimentale est implémentée pour exécuter des modèles d'appareils côté système hôte dom0, permettant l'émulation de périphériques matériels arbitraires pour les systèmes invités basés sur l'architecture ARM. Pour ARM, la prise en charge de SMMUv3 (System Memory Management Unit) est également implémentée, ce qui améliore la sécurité et la fiabilité des périphériques de transfert dans les systèmes ARM.
On peut aussi trouver que capacité supplémentaire d'utiliser le mécanisme de suivi matériel IPT (Intel Processor Trace), qui est apparu à partir du processeur Intel Broadwell, pour exporter des données à partir de systèmes invités pour les utilitaires de débogage s'exécutant du côté du système hôte. Par exemple, vous pouvez utiliser VMI Kernel Fuzzer ou DRAKVUF Sandbox.
Ajout de la prise en charge des environnements Viridian (Hyper-V) pour exécuter des invités Windows en utilisant plus de 64 processeurs virtuels et Couche PV Shim repensée utilisé pour exécuter des invités paravirtualisés (PV) non modifiés dans des environnements PVH et HVM (permet aux invités plus âgés de fonctionner dans des environnements plus sécurisés offrant une isolation plus stricte) La nouvelle version prise en charge améliorée de l'exécution des systèmes invités photovoltaïques dans les environnements qui ne prennent en charge que le mode HVM. Réduction de la taille de l'intercalaire, grâce à la réduction du code HVM spécifique.
Parmi les autres changements qui ressortent:
- En collaboration avec le projet Zephyr, un ensemble d'exigences de codage et de directives basées sur la norme MISRA_C est en cours d'élaboration pour réduire le risque de problèmes de sécurité. Les analyseurs statiques sont utilisés pour détecter les écarts avec les règles créées.
- Lancement de l'initiative Hyperlaunch pour fournir des outils flexibles pour configurer un ensemble statique de machines virtuelles à exécuter au moment du démarrage.
- Les capacités des contrôleurs VirtIO sur les systèmes ARM ont été améliorées car une implémentation de serveur IOREQ est proposée, qui devrait être utilisée à l'avenir pour améliorer la virtualisation des E / S à l'aide des protocoles VirtIO.
- Les travaux se poursuivent sur l'implémentation d'un port Xen pour les processeurs RISC-V. Actuellement, du code est en cours de développement pour gérer la mémoire virtuelle côté hôte et côté invité, ainsi que pour créer du code spécifique à l'architecture RISC-V.
- L'initiative a proposé le concept de domB (boot domain, dom0less), qui permet de s'affranchir de l'implémentation de l'environnement dom0 lors du démarrage de machines virtuelles à un stade précoce du démarrage du serveur.
- L'intégration continue a permis les tests Xen sur Alpine Linux et Ubuntu 20.04.
- Tests CentOS 6 rejetés.
- Les tests dom0 / domU basés sur QEMU ont été ajoutés à l'environnement d'intégration continue pour ARM.
Enfin, si vous souhaitez en savoir plus, vous pouvez vérifier les détails dans le lien suivant.