Após um ano de desenvolvimento, foi lançado o hypervisor livre Xen 4.17. Empresas como Amazon, Arm, Bitdefender, Citrix, EPAM Systems e Xilinx (AMD) participaram do desenvolvimento da nova versão. A formação de atualizações para a ramificação Xen 4.17 continuará até 12 de junho de 2024, e a publicação de correções de vulnerabilidades até 12 de dezembro de 2025.
Principais mudanças no Xen 4.17:
- Foi garantida conformidade parcial com os requisitos de desenvolvimento de software seguro e confiável na linguagem C, conforme especificações MISRA-C, que são aplicadas na criação de sistemas críticos. Quatro diretrizes e 24 regras MISRA-C (de 143 regras e 16 diretrizes) foram oficialmente implementadas no Xen, além da integração no processo de construção do analisador estático MISRA-C, que verifica o cumprimento dos requisitos da especificação.
- Foi disponibilizada a possibilidade de definir uma configuração estática do Xen para sistemas ARM, que determina rigidamente todos os recursos necessários para inicializar os sistemas convidados. Todos os recursos, como memória compartilhada, canais de notificação de eventos e espaço na pilha do hypervisor, são alocados previamente durante a inicialização do hypervisor, em vez de serem alocados dinamicamente, eliminando possíveis falhas devido à falta de recursos durante a operação.
- Para sistemas embarcados baseados na arquitetura ARM, foi implementado um suporte experimental (tech preview) à virtualização de entrada/saída utilizando protocolos VirtIO. O transporte virtio-mmio foi empregado para a troca de dados com o dispositivo virtual de entrada/saída, garantindo compatibilidade com uma ampla gama de dispositivos VirtIO. Foi implementado suporte para front-end para Linux, ferramentas (libxl/xl), modo dom0less e backends executados no espaço do usuário (foram testados os backends virtio-disk, virtio-net, i2c e gpio).
- Melhorou-se o suporte ao modo dom0less, permitindo operar sem a necessidade de implantar um ambiente dom0 durante a inicialização máquinas virtuais Na fase inicial de carregamento do servidor. Foi adicionada a possibilidade de definir pools de CPU (CPUPOOL) durante o carregamento (através da árvore de dispositivos), permitindo o uso de pools em configurações sem dom0, por exemplo, para vincular diferentes tipos de núcleos de CPU em sistemas ARM baseados na arquitetura big.LITTLE, que combinam em um único chip núcleos poderosos, porém de alto consumo energético, e núcleos menos potentes, mas mais eficientes em termos de energia. Além disso, no dom0less, foi possibilitada a vinculação do frontend/backend de paravirtualização aos sistemas convidados, permitindo o carregamento de sistemas convidados com dispositivos paravirtualizados necessários.
- Em sistemas ARM, as estruturas de virtualização de memória (P2M, Physical to Machine) agora são alocadas a partir do pool de memória formado na criação do domínio, o que possibilita aumentar a eficiência da isolamento entre sistemas convidados em caso de falhas relacionadas à memória.
- Para sistemas ARM, foi adicionada proteção contra a vulnerabilidade Spectre-BHB nas estruturas microarquitetônicas dos processadores.
- Em sistemas ARM, foi possibilitado o início do sistema operacional Zephyr no ambiente root do Dom0.
- Foi viabilizada a compilação separada (out-of-tree) do hipervisor.
- Em sistemas x86, foi assegurado o suporte a grandes páginas IOMMU (superpage) para todos os tipos de sistemas convidados, o que aumenta a largura de banda ao passar dispositivos PCI. Foi adicionado suporte a hosts equipados com até 12 TB de RAM. Na fase de carregamento, foi implementada a capacidade de definir parâmetros cpuid para dom0. Para gerenciar medidas de proteção contra ataques ao CPU nos sistemas convidados implementados ao nível do hipervisor, foram propostos parâmetros VIRT_SSBD e MSR_SPEC_CTRL.
- Separadamente, está sendo desenvolvido o transporte VirtIO-Grant, que se diferencia do VirtIO-MMIO por um nível mais elevado de segurança e pela capacidade de executar manipuladores em um domínio isolado separado para drivers. No VirtIO-Grant, em vez do mapeamento direto da memória, é utilizada a tradução de endereços físicos do sistema convidado em referências de concessão, o que permite o uso de áreas de memória compartilhada previamente acordadas para troca de dados entre o sistema convidado e o backend VirtIO, sem conceder ao backend permissões para mapeamento de memória. O suporte ao VirtIO-Grant já está implementado no kernel Linux, mas ainda não foi incluído nos backends QEMU, em virtio-vhost e nas ferramentas (libxl/xl).
- O desenvolvimento da iniciativa Hyperlaunch continua, visando fornecer ferramentas flexíveis para a configuração do lançamento de máquinas virtuais durante a inicialização do sistema. Já está pronto o primeiro conjunto de patches que permitem a identificação de domínios PV e a transmissão de suas imagens ao hipervisor durante a inicialização. Também foi implementado tudo o que é necessário para a inicialização de tais paravirtualizados. domínios, incluindo os componentes Xenstore para drivers PV. Após a aceitação dos patches, começará o trabalho para incluir suporte a dispositivos PVH e HVM, bem como a implementação de um domínio separado domB (domínio de construção), adequado para organizar a inicialização mensurada (measured boot), comprovando a integridade de todos os componentes carregados.
- Continuam os trabalhos na criação do porta Xen para a arquitetura RISC-V.
Fonte: opennet.ru
