O Protected KVM (pKVM), a solução de virtualização confidencial da Arm para Linux, está prestes a receber uma de suas peças mais cruciais: um driver para a IOMMU SMMUv3. Uma massiva série de 28 patches (v4) implementa o suporte para que o hypervisor do pKVM possa gerenciar de forma segura o acesso de dispositivos de hardware à memória — um passo fundamental rumo ao device passthrough em ambientes confidenciais no ARM64. Publicada em 19 de agosto de 2025, a série sinaliza trabalho destinado a uma próxima janela de merge (provavelmente Linux 6.18 ou posterior).
Pense no pKVM como um cofre de alta segurança para suas máquinas virtuais. Até agora, o cofre já protegia a memória da VM contra o sistema operacional hospedeiro, mas a “porta de serviço” para dispositivos (NICs, GPUs, controladoras NVMe) permanecia um ponto sensível. O novo driver SMMUv3 funciona como um controle de acesso biométrico nessa porta: o hypervisor (o guarda do cofre) inspeciona cada operação de DMA, valida e aplica as regras antes de deixar qualquer byte passar. Essa estratégia se materializa via trap-and-emulate — o hypervisor intercepta as tentativas do host de programar a SMMU e emula com segurança as operações permitidas.
Protegendo a porta dos fundos: o papel da IOMMU na virtualização confidencial
Em pKVM, o host é parte não-confiável. Para que uma VM confidencial possa usar um dispositivo físico (por exemplo, uma placa de rede), é preciso garantir que o dispositivo só enxergue as regiões de memória definidas pela política de isolamento do hypervisor. É aqui que entram SMMUv3 e IOMMU: o hypervisor “toma posse” da SMMU para isolar DMA de dispositivos do host e garantir que nenhum caminho contorne as proteções de memória da VM. A própria série de patches deixa explícito: sob pKVM, o host não tem acesso à memória do convidado ou do hypervisor, então dispositivos do host precisam ser isolados pela SMMU — e o hypervisor deve controlá-la.
Na prática, isso habilita o objetivo que faltava para o pKVM virar uma solução completa de virtualização confidencial: device passthrough seguro. O mapeamento de endereços de dispositivos passa a ser auditado e aplicado pelo hypervisor, impedindo que configurações maliciosas do host exponham ou corrompam dados dentro do cofre. É a base para cenários de alto desempenho (por exemplo, IO de baixa latência com NICs SR-IOV) sem abrir mão do isolamento.
De paravirtualização a trap-and-emulate: a evolução do design
A trajetória até aqui foi longa. As primeiras versões dessa proposta apostaram em uma interface de paravirtualization (pv interface) entre o driver do host e o hypervisor. Na v3, o foco recuou para “apenas isolamento de DMA” ainda baseado em pv. O feedback da comunidade foi duro: manter um driver separado e uma interface pv robusta seria complexo e frágil a longo prazo. A v4 muda de marcha e adota o “fim do jogo”: trap-and-emulate com tradução aninhada (nested translation) em SMMUv3. Em vez de ensinar o host a “conversar” com o hypervisor, a nova abordagem intercepta os acessos de MMIO da SMMU e emula somente o que o Linux usa, deixando o hypervisor no controle total.
Essa guinada tem motivação técnica clara: o hypervisor nVHE do pKVM é propositalmente mínimo; portar o driver completo do host para dentro do hypervisor não é viável. Com trap-and-emulate, um driver reduzido no hypervisor popula filas/comandos e tabelas da SMMU, enquanto o driver do host segue cuidando de descoberta e inicialização — mas sem autoridade final. É um meio-termo que preserva simplicidade no hypervisor e, ao mesmo tempo, reforça o isolamento.
Como o driver funciona (por dentro)
A essência do desenho é “armadilha” nos registradores de MMIO da SMMUv3 e “espelhamento” (shadow) das estruturas críticas, com o hypervisor higienizando cada operação:
- Command Queue (CMDQ): o hypervisor aloca uma fila “sombra”, captura escritas nos registradores de base/produtor/consumidor e consome os comandos do host após sanitização (por exemplo, alertando se o host tentar opcodes proibidos).
- Stream Table (ST/STE): primeira camada de tabela é provisionada pelo hypervisor e, quando o host emite invalidações/configurações, o hypervisor copia/valida a STE do host e associa a tradução de estágio-2, mantendo a versão “sombra” como fonte da verdade.
- GBPA e registros de controle: o hypervisor fixa políticas seguras (ex.: abort) e devolve ao host “reflexos” controlados, para que nada altere o comportamento seguro durante a execução.
Além disso, a série implementa peças de infraestrutura para o modo KVM no driver da SMMU, altera a ordem de inicialização para que o driver do host suba depois que o hypervisor esteja ativo, e adiciona suporte à pilha io-pgtable específica do hypervisor. Entre os últimos patches, aparecem “Shadow the CPU stage-2 page table” e “Enable nesting”, que fecham o circuito da tradução aninhada — a base do passthrough seguro em ARM64.
O que já funciona, limitações e próximos passos
O autor descreve um conjunto claro de assunções e limitações nesta v4: o código emula apenas a fração da SMMUv3 usada pelo Linux; mudanças dinâmicas de formato/tamanho da stream table são restringidas; alguns comandos não utilizados são bloqueados por segurança. No momento, a detecção de hardware é via Device Tree; ACPI poderá vir depois. Há menção a erratas que limitam nested translation em certos SoCs (como MMU-700), levando a desativar o aninhamento nesses casos. A série foi testada no QEMU (somente S1, somente S2 e nested) e em placa Morello, com tamanhos de página de 4K, 16K e 64K. Também se discute uma otimização futura para compartilhar tabelas de página e reduzir re-espelhamentos quando RPM liga/desliga a SMMU com frequência.
Do ponto de vista de produto, isso significa que o Linux pKVM SMMUv3 está bem mais próximo de entregar device passthrough de alto desempenho sem abrir mão do isolamento: dispositivos podem ser atribuídos a VMs confidenciais e operar com latência previsível, mas sempre sob o olhar do hypervisor. Para quem opera clouds Arm, infra de borda ou mesmo Android com workloads de alto valor, a mensagem é direta: dá para aproximar o metal sem perder o “cofre”.
Por que importa: tática de segurança com performance
O charme do trap-and-emulate é que ele traz a decisão para o lugar certo: o hypervisor. Em vez de confiar que o host sempre jogará limpo ao programar a IOMMU, o pKVM passa a “ler os lábios” de cada escrita de MMIO e só executa o que cumpre as regras. Com isso, abre-se espaço para integrar SR-IOV, filas de alta taxa de pacotes e pipelines de GPU sem comprometer o contrato de confidencialidade — e sem reinventar todo o driver do host dentro do hypervisor. É um salto qualitativo rumo a um pKVM pronto para produção.
