O kernel Linux está fortalecendo sua implementação da Confidential Compute Architecture (CCA) da Arm. Uma nova série de patches habilita Realms (VMs confidenciais) a receber dados criptografados diretamente do firmware durante a inicialização. Pense no Realm como um cofre digital. Antes, para colocar um segredo lá dentro — a chave de desbloqueio do disco, um token de provisionamento, um blob de configuração — você precisava esperar o cofre “abrir a porta”, criando uma janelinha de risco. Agora, o firmware pode “deslizar” um envelope lacrado para dentro do cofre enquanto ele ainda está sendo montado. O kernel do Realm mapeia essa entrega especial como memória já protegida, de forma que o segredo nunca é exposto ao hypervisor ou ao SO hospedeiro. Isso fecha uma das lacunas mais sensíveis do caminho de inicialização e aproxima o ARM64 do ideal de uma cadeia de confiança ponta a ponta.
Como a mudança no ioremap habilita a nova funcionalidade
Tecnicamente, a virada de chave está no fluxo de mapeamento: o patch generaliza a decisão de quando usar mapeamentos criptografados no ioremap() dentro de um Realm. Antes, apenas regiões de “dispositivos confiáveis” (RIPAS_DEV) ganhavam mapeamento cifrado. A série passa a tratar qualquer região que não seja “vazia” (RIPAS_EMPTY) como protegida pelo RMM/RSI, incluindo RIPAS_RAM — ou seja, RAM de Realm com garantias do monitor. Resultado: áreas reservadas pelo firmware para dados confidenciais podem ser mapeadas de forma segura e direta pelo guest. É a peça que faltava para o firmware injetar segredos em memória protegida e o kernel consumi-los sem que virem “alvo fácil” no caminho.
Na prática, isso destrava dois canais padrão para segredos:
- EFI Coco secret area: a área de segredos do EFI, exposta a user space via securityfs pelo módulo
efi_secret, agora suportada no ARM64 (antes restrita ao x86_64). Quando o firmware preenche a tabela de segredos, o driver mapeia a região e publica os arquivos em/sys/kernel/security/secrets/coco. - ACPI CCEL (Confidential Computing Event Log): a tabela ACPI que aponta para o log de eventos de confidencialidade (medidas usadas na atestação). O patch trata memória EfiACPIMemoryNVS — reservada ao firmware após
ExitBootServices()— como somente leitura no kernel do Realm, eliminando o risco de exposição/alteração inadvertida.
Firmware, ACPI/EFI e a “entrega segura”
Por que NVS? Porque a especificação UEFI/ACPI indica que áreas EfiACPIReclaimMemory e EfiACPIMemoryNVS são reservadas ao firmware para tabelas/dados que sobrevivem à saída dos serviços de boot (o caso clássico para CCEL). Ao tratá-las com o devido cuidado — mapeando como RO e, quando aplicável, usando o novo caminho criptografado — o Realm evita duas classes de problema: vazamento para o hypervisor e corrupção acidental do log/tabela durante o boot do guest. É uma medida simples na superfície, mas crucial para manter a trilha de evidências da atestação íntegra e para entregar segredos de forma confidencial já no primeiro sopro de vida da VM.
Status de upstream e o que esperar
Os patches foram enviados por Suzuki K Poulose (Arm), com Reviewed-by e Tested-by de engenheiros ativos no ecossistema CCA. A série v3 foi publicada em 18 de setembro de 2025 e recebeu acompanhamento na lista linux-arm-kernel, incluindo discussão de detalhes como o tratamento exato de EfiACPIMemoryNVS e referências às especificações UEFI/ACPI. Em paralelo, o suporte a segredos via EFI/efi_secret e a exposição de CCEL já estão consolidados no ecossistema Linux, e o tópico CCA vem avançando com outros merges recentes no ramo arm64/for-next. Com isso, a expectativa — dada a janela do calendário — é de que essa funcionalidade entre no ciclo de Linux 6.18, completando mais um pedaço da história de ARM64 Confidential Computing no kernel principal.
