Después de un año de desarrollo, se ha publicado la versión del hipervisor libre Xen 4.17. En el desarrollo de esta nueva versión participaron empresas como Amazon, Arm, Bitdefender, Citrix, EPAM Systems y Xilinx (AMD). La formación de actualizaciones para la rama Xen 4.17 se extenderá hasta el 12 de junio de 2024, mientras que la publicación de correcciones de vulnerabilidades se realizará hasta el 12 de diciembre de 2025.
Cambios clave en Xen 4.17:
- Se ha asegurado el cumplimiento parcial de los requisitos para el desarrollo de software seguro y confiable en lenguajes como C, establecidos en las especificaciones MISRA-C, que son utilizadas en la creación de sistemas críticos. En Xen se han implementado oficialmente 4 directivas y 24 reglas de MISRA-C (de 143 reglas y 16 directivas), y se ha integrado en los procesos de construcción el analizador estático MISRA-C, que verifica el cumplimiento de los requisitos de la especificación.
- Se ha proporcionado la posibilidad de definir una configuración estática de Xen para sistemas ARM, que establece de forma rígida todos los recursos necesarios para cargar sistemas invitados. Todos los recursos, como la memoria compartida, los canales para la notificación de eventos y el espacio en la pila del hipervisor, se distribuyen de antemano al iniciar el hipervisor, en lugar de asignarse dinámicamente, lo que elimina posibles fallos debido a la falta de recursos durante la operación.
- Para sistemas integrados basados en la arquitectura ARM, se ha implementado un soporte experimental (tech preview) para la virtualización de entrada/salida utilizando protocolos VirtIO. Para el intercambio de datos con el dispositivo virtual de entrada/salida se utiliza el transporte virtio-mmio, lo que ha permitido garantizar la compatibilidad con una amplia gama de dispositivos VirtIO. Se ha implementado un soporte para el frontend de Linux, herramientas (libxl/xl), modo dom0less y backends que se ejecutan en espacio de usuario (se han probado los backends virtio-disk, virtio-net, i2c y gpio).
- Se ha mejorado el soporte para el modo dom0less, que permite prescindir del despliegue del entorno dom0 al iniciar. máquinas virtuales en las primeras etapas de carga del servidor. Se ha proporcionado la capacidad de definir grupos de CPU (CPUPOOL) durante la carga (a través del árbol de dispositivos), lo que permite utilizar los grupos en configuraciones sin dom0, por ejemplo, para asignar diferentes tipos de núcleos de CPU en sistemas ARM basados en la arquitectura big.LITTLE, que combinan en un mismo chip núcleos potentes pero con alto consumo de energía y núcleos menos potentes, pero más eficientes energéticamente. Además, en entornos sin dom0 se ha proporcionado la capacidad de vincular el frontend/backend de la paravirtualización a sistemas invitados, lo que permite iniciar sistemas invitados con los dispositivos paravirtualizados necesarios.
- En sistemas ARM, las estructuras de virtualización de memoria (P2M, Physical to Machine) ahora se asignan desde el grupo de memoria generado al crear un dominio, lo que mejora la eficacia de la aislamiento entre sistemas invitados cuando ocurren errores relacionados con la memoria.
- Para sistemas ARM se ha añadido protección contra la vulnerabilidad Spectre-BHB en las estructuras microarquitectónicas de los procesadores.
- En sistemas ARM se ha habilitado la posibilidad de iniciar el sistema operativo Zephyr en el entorno raíz de Dom0.
- Se ha proporcionado la capacidad de compilar el hypervisor de forma separada (out-of-tree).
- En sistemas x86, se ha garantizado el soporte de grandes páginas IOMMU (superpage) para todos los tipos de sistemas invitados, lo que permite aumentar el ancho de banda al pasar dispositivos PCI. Se ha añadido soporte para hosts con hasta 12 TB de RAM. En la etapa de carga se ha implementado la posibilidad de establecer parámetros de cpuid para dom0. Para la gestión de las medidas de seguridad contra ataques a la CPU en sistemas invitados implementadas a nivel de hypervisor, se han propuesto parámetros VIRT_SSBD y MSR_SPEC_CTRL.
- Se está desarrollando por separado el transporte VirtIO-Grant, que se diferencia de VirtIO-MMIO por su mayor nivel de seguridad y la posibilidad de ejecutar controladores en un dominio aislado separado. En VirtIO-Grant, en lugar de un mapeo directo de la memoria, se utiliza la traducción de direcciones físicas del sistema invitado a referencias de grant, lo que permite el uso de áreas preacordadas de memoria compartida para el intercambio de datos entre el sistema invitado y el backend de VirtIO, sin otorgar al backend derechos para realizar el mapeo de memoria. El soporte para VirtIO-Grant ya se ha implementado en el núcleo de Linux, pero aún no se ha incluido en los backends de QEMU, en virtio-vhost y en el toolkit (libxl/xl).
- Continúa el desarrollo de la iniciativa Hyperlaunch, dirigida a proporcionar herramientas flexibles para la configuración de lanzamiento de máquinas virtuales durante el arranque del sistema. Actualmente ya está listo el primer conjunto de parches que permiten identificar dominios PV y transferir sus imágenes al hipervisor durante el arranque. También se ha implementado todo lo necesario para ejecutar tales paravirtualizados dominios, incluidos los componentes Xenstore para controladores PV. Tras la aprobación de los parches, comenzará el trabajo para incluir soporte para dispositivos PVH y HVM, así como la implementación de un dominio separado domB (dominio de compilación), adecuado para organizar arranques medidos (measured boot), que validen la autenticidad de todos los componentes que se cargan.
- Continúa el trabajo en la creación de un puerto Xen para la arquitectura RISC-V.
Fuente: opennet.ru
