Xen 4.15 llega con soporte de actualización en vivo, mejoras para ARM y mas

Después de ocho meses de desarrollo se acaba de realizar el lanzamiento de la nueva versión del hipervisor gratuito Xen 4.15 y en esta nueva versión las actualizaciones para la rama Xen 4.15 durará hasta el 8 de octubre de 2022 y la publicación de correcciones de vulnerabilidades hasta el 8 de abril de 2024.

Para quienes desconocen de Xen, deben saber que es un monitor de máquina virtual de código abierto desarrollado por la Universidad de Cambridge. La meta del diseño es poder ejecutar instancias de sistemas operativos con todas sus características, de forma completamente funcional en un equipo sencillo.

Xen proporciona aislamiento seguro, control de recursos, garantías de calidad de servicio y migración de máquinas virtuales en caliente. Los sistemas operativos pueden ser modificados explícitamente para correr Xen (aunque manteniendo la compatibilidad con aplicaciones de usuario).

Principales novedades en Xen 4.15

En esta nueva versión en los procesos Xenstored y Oxenstored se ha añadido el soporte experimental para actualizaciones en vivo, lo que  permite entregar y aplicar correcciones de vulnerabilidades sin reiniciar el entorno host, además de que se añadió el soporte para imágenes de arranque unificadas, lo que permite crear imágenes del sistema que incluyen componentes Xen. Estas imágenes se empaquetan como un único binario EFI que se puede usar para iniciar un sistema Xen en ejecución directamente desde un administrador de inicio EFI sin cargadores de inicio intermedios como GRUB. La imagen incluye componentes de Xen como el hipervisor, el kernel para el entorno de host (dom0), initrd, Xen KConfig, la configuración de XSM y el árbol de dispositivos.

Para la plataforma ARM, se implementa una posibilidad experimental de ejecutar modelos de dispositivos en el lado del sistema host dom0, lo que permite emular dispositivos de hardware arbitrarios para sistemas invitados basados ​​en la arquitectura ARM. Para ARM, también se implementa soporte para SMMUv3 (Unidad de administración de memoria del sistema), que mejora la seguridad y confiabilidad de los dispositivos de reenvío en los sistemas ARM.

También podremos encontrar que se agregó la capacidad de usar el mecanismo de seguimiento de hardware IPT (Intel Processor Trace), que apareció comenzando con la CPU Intel Broadwell, para exportar datos de sistemas invitados para depurar utilidades que se ejecutan en el lado del sistema host. Por ejemplo, puede utilizar VMI Kernel Fuzzer o DRAKVUF Sandbox.

Se agregó soporte para entornos Viridian (Hyper-V) para ejecutar invitados de Windows utilizando más de 64 CPU virtuales y se rediseñó la capa PV Shim utilizada para ejecutar invitados paravirtualizados (PV) no modificados en entornos PVH y HVM (permite que los huéspedes mayores corran en entornos más seguros que proporcionan un aislamiento más estricto). La nueva versión ha mejorado el soporte para ejecutar sistemas invitados PV en entornos que solo admiten el modo HVM. Reducción del tamaño de la capa intermedia, gracias a la reducción del código específico de HVM.

De los demás cambios que se destacan:

• Junto con el proyecto Zephyr, se está desarrollando un conjunto de requisitos y pautas de codificación basados ​​en el estándar MISRA_C para reducir el riesgo de problemas de seguridad. Los analizadores estáticos se utilizan para detectar discrepancias con las reglas creadas.
• Se Presentó la iniciativa Hyperlaunch para proporcionar herramientas flexibles para configurar un conjunto estático de máquinas virtuales para que se ejecuten en el momento del arranque.
• Las capacidades de los controladores VirtIO en sistemas ARM fueron mejoradas pues se propone una implementación del servidor IOREQ, que se planea utilizar en el futuro para mejorar la virtualización de E/S utilizando los protocolos VirtIO.
• Continúa el trabajo en la implementación de un puerto Xen para procesadores RISC-V. Actualmente, se está desarrollando código para administrar la memoria virtual en el lado del host y del invitado, así como para la creación de código específico para la arquitectura RISC-V.
• La iniciativa propuso el concepto de domB (dominio de arranque, dom0less), que permite prescindir de la implementación del entorno dom0 al iniciar máquinas virtuales en una etapa temprana del inicio del servidor.
• La integración continua habilitó las pruebas de Xen en Alpine Linux y Ubuntu 20.04.
• Pruebas descartadas CentOS 6.
• Se agregaron pruebas dom0/domU basadas en QEMU al entorno de integración continua para ARM.

Finalmente si quieres conocer más al respecto, puedes consultar los detalles en el siguiente enlace.