Después de ocho meses de desarrollo, se ha publicado la versión del hipervisor libre Xen 4.16. En el desarrollo de esta nueva versión participaron empresas como Amazon, Arm, Bitdefender, Citrix y EPAM Systems. Las actualizaciones para la rama Xen 4.16 continuarán hasta el 2 de junio de 2023, y la publicación de correcciones de vulnerabilidades se extenderá hasta el 2 de diciembre de 2024.
Cambios clave en Xen 4.16:
- En TPM Manager, que permite el funcionamiento de chips virtuales para el almacenamiento de claves criptográficas (vTPM) implementados sobre un TPM físico común (Trusted Platform Module), se han realizado correcciones para facilitar el soporte de la especificación TPM 2.0.
- Se ha aumentado la dependencia del módulo PV Shim, utilizado para ejecutar sistemas invitados paravirtualizados no modificados (PV) en entornos PVH y HVM. En adelante, el uso de sistemas invitados paravirtualizados de 32 bits será posible únicamente en modo PV Shim, lo que reducirá el número de puntos en el hipervisor que podrían ser vulnerables.
- Se ha añadido la capacidad de iniciar en dispositivos Intel sin temporizador programable (PIT, Programmable Interval Timer).
- Se ha limpiado componentes obsoletos, y se ha dejado de compilar por defecto el código 'qemu-xen-traditional' y PV-Grub (la necesidad de datos específicos para forks de Xen ha desaparecido tras la incorporación de cambios con soporte para Xen en la rama principal de QEMU y Grub).
- Para sistemas invitados con arquitectura ARM, se ha implementado soporte inicial para contadores de rendimiento virtualizados (Performance Monitor Counters).
- Se ha mejorado el soporte para el modo dom0less, que permite prescindir del despliegue del entorno dom0 al iniciar. máquinas virtuales en la etapa temprana de inicio del servidor. Los cambios realizados han permitido el soporte para sistemas ARM de 64 bits con firmware EFI.
- Se ha mejorado el soporte para sistemas de 64 bits heterogéneos ARM basados en la arquitectura big.LITTLE, que combinan en un único chip núcleos potentes pero con alto consumo de energía, y núcleos menos potentes pero más eficientes energéticamente.
Al mismo tiempo, Intel publicó la versión 20.0 de su hipervisor Cloud Hypervisor, construido sobre componentes del proyecto conjunto Rust-VMM, en el que también participan Alibaba, Amazon, Google y Red Hat. Rust-VMM está escrito en el lenguaje Rust y permite crear hipervisores específicos para tareas determinadas. Cloud Hypervisor es uno de esos hipervisores, que proporciona un monitor de máquinas virtuales (VMM) de alto nivel, funcionando sobre KVM y optimizado para resolver problemas propios de sistemas en la nube. El código del proyecto está disponible bajo la licencia Apache 2.0.
Cloud Hypervisor se centra en ejecutar distribuciones modernas de Linux utilizando dispositivos paravirtualizados basados en virtio. Entre las principales tareas se mencionan: alta capacidad de respuesta, bajo consumo de memoria, alto rendimiento, simplificación de la configuración y reducción de posibles vectores de ataque. La emulación se ha minimizado y se prioriza la paravirtualización. Actualmente, solo se admiten sistemas x86_64, pero se planea la compatibilidad con AArch64. Por el momento, solo se admiten compilaciones de Linux de 64 bits. La configuración de CPU, memoria, PCI y NVDIMM se realiza en la fase de construcción. Se prevé la posibilidad de migrar máquinas virtuales entre servidores.
En la nueva versión:
- Para las arquitecturas x86_64 y aarch64 ahora se permite crear hasta 16 segmentos PCI, lo que aumenta el número total de dispositivos PCI permitidos de 31 a 496.
- Se ha implementado el soporte para la asignación de CPUs virtuales a núcleos físicos de CPU (CPU pinning). Ahora se puede definir un conjunto limitado de CPUs host en las que se permite la ejecución de cada vCPU, lo cual puede ser útil para la asignación directa (1:1) de recursos entre el host y el sistema huésped o al ejecutar una máquina virtual en un nodo específico de NUMA.
- Se ha mejorado el soporte para la virtualización de entrada/salida. Cada región de VFIO ahora puede ser reflejada en memoria, lo que reduce el número de operaciones de salida de la máquina virtual y permite mejorar el rendimiento del paso de dispositivos a la máquina virtual.
- En el código en lenguaje Rust se han realizado trabajos para reemplazar secciones unsafe por implementaciones alternativas que se ejecutan en modo safe. Para las secciones unsafe restantes, se han añadido comentarios detallados que explican por qué el código unsafe dejado puede considerarse seguro.
Fuente: opennet.ru
