Após um ano de desenvolvimento, foi publicado o lançamento do hipervisor gratuito Xen 4.17. Empresas como Amazon, Arm, Bitdefender, Citrix, EPAM Systems e Xilinx (AMD) contribuíram para o desenvolvimento da nova versão. A formação de atualizações para o branch Xen 4.17 durará 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:
- Assegurou o cumprimento parcial dos requisitos para o desenvolvimento de programas seguros e confiáveis na linguagem C, formulados nas especificações MISRA-C utilizadas na criação de sistemas críticos. O Xen implementa oficialmente 4 diretivas e 24 regras MISRA-C (de 143 regras e 16 diretivas), bem como integração nos processos de montagem do analisador estático MISRA-C, que verifica o cumprimento dos requisitos da especificação.
- Forneceu a capacidade de definir uma configuração estática do Xen para sistemas ARM que codifica antecipadamente todos os recursos necessários para inicializar sistemas convidados. Todos os recursos, como memória compartilhada, canais de notificação de eventos e espaço de heap do hipervisor, são pré-alocados na inicialização do hipervisor, em vez de serem alocados dinamicamente, eliminando a possibilidade de falhas devido à falta de recursos.
- Para sistemas embarcados baseados na arquitetura ARM, foi implementado suporte experimental (visualização técnica) para virtualização de E/S usando os protocolos VirtIO. O transporte virtio-mmio é utilizado para comunicação com o dispositivo de E/S virtual, o que possibilitou garantir a compatibilidade com uma ampla gama de dispositivos VirtIO. Implementado suporte para frontend Linux, kit de ferramentas (libxl/xl), modo dom0less e backends de espaço de usuário (backends virtio-disk, virtio-net, i2c e gpio testados).
- Suporte aprimorado para o modo dom0less, que permite evitar a implantação de um ambiente dom0 ao iniciar máquinas virtuais em um estágio inicial da inicialização do servidor. É fornecida a capacidade de definir pools de CPU (CPUPOOL) no estágio de inicialização (via árvore de dispositivos), o que permite usar 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 , combinando núcleos poderosos, mas que consomem muita energia, e núcleos menos produtivos, mas com maior eficiência energética. Além disso, dom0less oferece a capacidade de vincular o frontend/backend de paravirtualização aos convidados, o que permite inicializar os convidados com os 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 criado quando um domínio é criado, permitindo melhor isolamento entre convidados quando ocorrem falhas relacionadas à memória.
- Adicionada proteção contra a vulnerabilidade Spectre-BHB em estruturas de microarquitetura de processador para sistemas ARM.
- Em sistemas ARM, é fornecida a capacidade de executar o sistema operacional Zephyr no ambiente raiz Dom0.
- É fornecida a possibilidade de um conjunto de hipervisor separado (fora da árvore).
- Em sistemas x86, grandes páginas IOMMU (superpage) são suportadas para todos os tipos de sistemas convidados, o que permite aumentar o rendimento ao encaminhar dispositivos PCI. Adicionado suporte para hosts com até 12 TB de RAM. No estágio de inicialização, a capacidade de definir parâmetros CPUID para dom0 é implementada. Os parâmetros VIRT_SSBD e MSR_SPEC_CTRL são propostos para controlar as medidas de proteção em nível de hipervisor contra ataques à CPU em sistemas convidados.
- Separadamente, está sendo desenvolvido o transporte VirtIO-Grant, que difere do VirtIO-MMIO por um nível mais alto 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 de memória, é utilizada a tradução dos endereços físicos do convidado em links de concessão, o que permite o uso de áreas de memória compartilhada pré-acordadas para troca de dados entre o sistema convidado e o backend do VirtIO, sem conceder o backend os direitos para realizar mapeamento de memória. O suporte VirtIO-Grant já está implementado no kernel Linux, mas ainda não está incluído nos backends QEMU, virtio-vhost e kit de ferramentas (libxl/xl).
- A iniciativa Hyperlaunch continua a ser desenvolvida para fornecer ferramentas flexíveis para personalizar o lançamento de máquinas virtuais no momento da inicialização do sistema. Atualmente, o primeiro conjunto de patches já está pronto, permitindo definir domínios PV e transferir suas imagens para o hipervisor durante o carregamento. Tudo o que é necessário para executar esses domínios paravirtualizados também é implementado, incluindo componentes Xenstore para drivers PV. Após a aceitação dos patches, começarão os trabalhos para habilitar o suporte para dispositivos PVH e HVM, bem como a implementação de um domB (domínio construtor) separado adequado para organizar uma inicialização medida (inicialização medida), confirmando a validade de todos os componentes carregados.
- O trabalho continua em uma porta Xen para a arquitetura RISC-V.
Fonte: opennet.ru