Despois dun ano de desenvolvemento, lanzouse o hipervisor gratuíto Xen 4.17. No desenvolvemento da nova versión participaron empresas como Amazon, Arm, Bitdefender, Citrix, EPAM Systems e Xilinx (AMD). A xeración de actualizacións para a rama Xen 4.17 durará ata o 12 de xuño de 2024 e a publicación de correccións de vulnerabilidades ata o 12 de decembro de 2025.
Cambios clave en Xen 4.17:
- O cumprimento parcial dos requisitos para o desenvolvemento de programas seguros e fiables en linguaxe C, formulados nas especificacións MISRA-C utilizadas na creación de sistemas de misión crítica. Xen implementa oficialmente 4 directivas e 24 regras MISRA-C (de 143 regras e 16 directivas), e tamén integra o analizador estático MISRA-C nos procesos de montaxe, que verifica o cumprimento dos requisitos das especificacións.
- Ofrece a posibilidade de definir unha configuración Xen estática para sistemas ARM, que codifica todos os recursos necesarios para iniciar os convidados con antelación. Todos os recursos, como a memoria compartida, as canles de notificación de eventos e o espazo do montón do hipervisor, asignáronse previamente no inicio do hipervisor en lugar de asignarse de forma dinámica, eliminando posibles fallos debidos á escaseza de recursos durante o funcionamento.
- Para sistemas integrados baseados na arquitectura ARM, implementouse o soporte experimental (vista previa técnica) para a virtualización de E/S mediante protocolos VirtIO. O transporte virtio-mmio úsase para intercambiar datos cun dispositivo de E/S virtual, o que garante a compatibilidade cunha ampla gama de dispositivos VirtIO. Implementouse o soporte para a interface Linux, o kit de ferramentas (libxl/xl), o modo dom0less e os backends que se executan no espazo do usuario (probáronse os backends virtio-disk, virtio-net, i2c e gpio).
- Compatibilidade mellorada para o modo dom0less, que permite evitar a implantación do ambiente dom0 ao iniciar máquinas virtuais nunha fase inicial do inicio do servidor. É posible definir agrupacións de CPU (CPUPOOL) na fase de arranque (a través da árbore de dispositivos), o que lle permite utilizar agrupacións en configuracións sen dom0, por exemplo, para vincular diferentes tipos de núcleos de CPU en sistemas ARM baseados no big.LITTLE arquitectura, que combina núcleos potentes, pero consumidores de enerxía, e núcleos menos produtivos pero máis eficientes enerxéticamente. Ademais, dom0less ofrece a posibilidade de vincular o frontend/backend de paravirtualización aos sistemas convidados, o que lle permite iniciar sistemas convidados cos dispositivos paravirtualizados necesarios.
- Nos sistemas ARM, as estruturas de virtualización de memoria (P2M, Physical to Machine) agora alócanse a partir da agrupación de memoria creada cando se crea o dominio, o que permite un mellor illamento entre os hóspedes cando se producen fallos relacionados coa memoria.
- Para os sistemas ARM, engadiuse protección contra a vulnerabilidade Spectre-BHB nas estruturas microarquitectónicas do procesador.
- Nos sistemas ARM, é posible executar o sistema operativo Zephyr no entorno raíz Dom0.
- Ofrécese a posibilidade dun conxunto de hipervisor separado (fóra da árbore).
- Nos sistemas x86, as páxinas IOMMU grandes (superpáxina) son compatibles con todo tipo de sistemas convidados, o que permite aumentar o rendemento ao reenviar dispositivos PCI. Engadido soporte para hosts equipados con ata 12 TB de RAM. Na fase de arranque, implementouse a capacidade de establecer os parámetros cpuid para dom0. Para controlar as medidas de protección implementadas a nivel de hipervisor contra ataques á CPU en sistemas convidados, propóñense os parámetros VIRT_SSBD e MSR_SPEC_CTRL.
- O transporte VirtIO-Grant estase a desenvolver por separado, diferenciándose de VirtIO-MMIO por un maior nivel de seguridade e a capacidade de executar controladores nun dominio illado separado para os condutores. VirtIO-Grant, en lugar da asignación directa de memoria, utiliza a tradución de enderezos físicos do sistema convidado en ligazóns de subvención, o que permite o uso de áreas de memoria compartida previamente acordadas para o intercambio de datos entre o sistema invitado e o backend de VirtIO, sen conceder os dereitos do back-end para realizar a asignación de memoria. O soporte de VirtIO-Grant xa está implementado no núcleo de Linux, pero aínda non está incluído nos backends QEMU, en virtio-vhost e no kit de ferramentas (libxl/xl).
- Continúase desenvolvendo a iniciativa Hyperlaunch, dirixida a proporcionar ferramentas flexibles para configurar o lanzamento de máquinas virtuais durante o arranque do sistema. Actualmente, xa está preparado o primeiro conxunto de parches que permite detectar dominios fotovoltaicos e transferir as súas imaxes ao hipervisor ao cargar. Tamén se implementou todo o necesario para executar estes dominios paravirtualizados, incluídos os compoñentes de Xenstore para controladores fotovoltaicos. Unha vez que se acepten os parches, comezarase a traballar para habilitar o soporte para dispositivos PVH e HVM, así como a implementación dun dominio domB separado (dominio do constructor), adecuado para organizar un arranque medido, confirmando a validez de todos os compoñentes cargados.
- Continúa o traballo na creación dun porto de Xen para a arquitectura RISC-V.
Fonte: opennet.ru