Después de un año de desarrollo, se ha publicado el lanzamiento del hipervisor gratuito Xen 4.17. Empresas como Amazon, Arm, Bitdefender, Citrix, EPAM Systems y Xilinx (AMD) han contribuido al desarrollo de la nueva versión. La formación de actualizaciones para la rama Xen 4.17 durará hasta el 12 de junio de 2024 y la publicación de correcciones de vulnerabilidades hasta el 12 de diciembre de 2025.
Cambios clave en Xen 4.17:
- Cumplimiento parcial de los requisitos para el desarrollo de programas seguros y confiables en lenguaje C, formulados en las especificaciones MISRA-C utilizadas en la creación de sistemas críticos. Xen implementa oficialmente 4 directivas y 24 reglas MISRA-C (de 143 reglas y 16 directivas), así como la integración en los procesos de ensamblaje del analizador estático MISRA-C, que verifica el cumplimiento de los requisitos de la especificación.
- Proporcionó la capacidad de definir una configuración estática de Xen para sistemas ARM que codifica por adelantado todos los recursos necesarios para iniciar los sistemas invitados. Todos los recursos, como la memoria compartida, los canales para la notificación de eventos y el espacio de almacenamiento dinámico del hipervisor, se asignan previamente al inicio del hipervisor en lugar de asignarse dinámicamente, lo que elimina posibles cuellos de botella de recursos durante el funcionamiento.
- Para los sistemas integrados basados en la arquitectura ARM, se ha implementado soporte experimental (vista previa técnica) para la virtualización de E/S utilizando los protocolos VirtIO. El transporte virtio-mmio se utiliza para comunicarse con el dispositivo de E / S virtual, lo que permitió garantizar la compatibilidad con una amplia gama de dispositivos VirtIO. Compatibilidad implementada para el frontend de Linux, el kit de herramientas (libxl/xl), el modo dom0less y los backends de espacio de usuario (virtio-disk, virtio-net, i2c y gpio backends probados).
- Compatibilidad mejorada con el modo dom0less, que permite evitar la implementación de un entorno dom0 al iniciar máquinas virtuales en una etapa temprana del arranque del servidor. Se proporciona la capacidad de definir grupos de CPU (CPUPOOL) en la etapa de arranque (a través del árbol de dispositivos), lo que permite usar grupos en configuraciones sin dom0, por ejemplo, para vincular diferentes tipos de núcleos de CPU en sistemas ARM basados en la arquitectura big.LITTLE , que combina núcleos potentes, pero que consumen energía, y núcleos menos productivos, pero más eficientes energéticamente. Además, dom0less brinda la capacidad de vincular el frontend/backend de paravirtualización a los invitados, lo que le permite iniciar a los invitados con los dispositivos paravirtualizados necesarios.
- En los sistemas ARM, las estructuras de virtualización de memoria (P2M, física a máquina) ahora se asignan desde el grupo de memoria creado cuando se crea un dominio, lo que permite un mejor aislamiento entre invitados cuando ocurren fallas relacionadas con la memoria.
- Se agregó protección contra la vulnerabilidad Spectre-BHB en las estructuras de microarquitectura del procesador para sistemas ARM.
- En los sistemas ARM, se proporciona la capacidad de ejecutar el sistema operativo Zephyr en el entorno raíz Dom0.
- Se proporciona la posibilidad de un ensamblaje de hipervisor separado (fuera del árbol).
- En los sistemas x86, se admiten páginas grandes de IOMMU (superpágina) para todos los tipos de sistemas invitados, lo que le permite aumentar el rendimiento al reenviar dispositivos PCI. Se agregó soporte para hosts con hasta 12 TB de RAM. En la etapa de arranque, se implementa la capacidad de establecer parámetros cpuid para dom0. Los parámetros VIRT_SSBD y MSR_SPEC_CTRL se proponen para controlar las medidas de protección a nivel de hipervisor contra ataques a la CPU en sistemas invitados.
- Por separado, se está desarrollando el transporte VirtIO-Grant, que difiere de VirtIO-MMIO en un mayor nivel de seguridad y la capacidad de ejecutar controladores en un dominio aislado separado para los controladores. En VirtIO-Grant, en lugar del mapeo de memoria directo, se usa la traducción de las direcciones físicas del sistema invitado en enlaces de concesión, lo que permite el uso de áreas de memoria compartida previamente acordadas para el intercambio de datos entre el sistema invitado y el backend de VirtIO, sin otorgando al backend los derechos para realizar el mapeo de memoria. La compatibilidad con VirtIO-Grant ya está implementada en el kernel de Linux, pero aún no está incluida en los backends de QEMU, virtio-vhost y toolkit (libxl/xl).
- La iniciativa Hyperlaunch continúa desarrollándose para proporcionar herramientas flexibles para personalizar el lanzamiento de máquinas virtuales en el momento del arranque del sistema. Actualmente, el primer conjunto de parches ya está listo, lo que le permite definir dominios PV y transferir sus imágenes al hipervisor al cargar. También se implementa todo lo necesario para ejecutar dichos dominios paravirtualizados, incluidos los componentes de Xenstore para controladores fotovoltaicos. Una vez que se acepten los parches, se comenzará a trabajar para habilitar la compatibilidad con dispositivos PVH y HVM, así como la implementación de un dominio domB separado (dominio de compilador), adecuado para organizar un arranque medido (arranque medido), confirmando la validez de todos los cargados. componentes
- Se continúa trabajando en un puerto Xen para la arquitectura RISC-V.
Fuente: opennet.ru