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.
- Implementouse compatibilidade experimental (vista previa tecnolóxica) para a virtualización de E/S mediante protocolos VirtIO para sistemas integrados baseados na arquitectura ARM. O transporte virtio-mmio úsase para o intercambio de datos co dispositivo de E/S virtual, o que garante a compatibilidade cunha ampla gama de dispositivos VirtIO. Implementouse compatibilidade frontend para Linux, cadea de ferramentas (libxl/xl), modo dom0less e backends que se executan no espazo de usuario (probáronse os backends virtio-disk, virtio-net, i2c e gpio).
- Mellorouse a compatibilidade co modo dom0less, que permite evitar a implementación dun ambiente dom0 ao inicio. máquinas virtuais Nunha fase inicial do arranque do servidor. Agora está dispoñible a capacidade de definir grupos de CPU (CPUPOOLs) no arranque (a través da árbore de dispositivos), o que permite o uso de grupos en configuracións sen dom0, por exemplo, para vincular diferentes tipos de núcleos de CPU en sistemas ARM baseados na arquitectura big.LITTLE, que combinan núcleos potentes pero que consumen moita enerxía con núcleos menos potentes pero máis eficientes enerxeticamente nun só chip. Ademais, dom0less ofrece a capacidade de vincular o frontend/backend de paravirtualización a sistemas invitados, o que permite que os sistemas invitados arranquen 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 está a ser desenvolvido por separado. Difire de VirtIO-MMIO en que ofrece un maior nivel de seguridade e a capacidade de executar controladores nun dominio de controlador separado e illado. En lugar do mapeo directo da memoria, VirtIO-Grant usa a tradución dos enderezos físicos do sistema convidado en ligazóns de concesión, o que permite o uso de rexións de memoria compartida preacordadas para o intercambio de datos entre o sistema convidado e o backend VirtIO, sen conceder permiso ao backend para realizar o mapeo de memoria. A compatibilidade con VirtIO-Grant xa está implementada no kernel. Linux, pero aínda non está incluído nos backends de QEMU, virtio-vhost ou a cadea de ferramentas (libxl/xl).
- A iniciativa Hyperlaunch, destinada a proporcionar ferramentas flexibles para configurar o lanzamento de máquinas virtuais durante o arranque do sistema, continúa a evolucionar. O primeiro conxunto de parches xa está listo, o que permite a detección de dominios PV e a transferencia das súas imaxes ao hipervisor durante o arranque. Tamén se implementou todo o necesario para lanzar estes sistemas paravirtualizados. dominios, incluíndo compoñentes de Xenstore para controladores PV. Unha vez aprobados os parches, comezará o traballo para habilitar a compatibilidade con dispositivos PVH e HVM, así como para implementar un domB (dominio do compilador) separado axeitado para o arranque medido, que verifica 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
