O Kernel Hardening Overlay (KHO), sistema pensado para preservar memória com segurança durante um kexec, está passando por uma grande reformulação. Uma nova série de patches RFC propõe torná-lo “stateless” (sem estado), trocando o mecanismo anterior — um rastreador baseado em xarray que precisava ser serializado antes do handover — por uma estrutura bem mais direta: um “mapa” de preservação construído com tabelas hierárquicas tipo page table e entregue como está ao próximo kernel via FDT (Flattened Device Tree). Em português claro: menos peças em movimento, menos chances de dar errado.
De xarray a “page tables”: a nova arquitetura
Imagine que o KHO precise deixar um mapa de quais páginas de memória devem ser mantidas para o kernel seguinte. No modelo antigo, o kernel “desenhava” esse mapa numa estrutura xarray, tirava uma “foto” (a serialização) e, só então, anexava esse pacote para o sucessor “revelar” e interpretar. Agora, a proposta é eliminar a foto. O kernel constrói uma estrutura já no formato do mapa — um arranjo hierárquico por ordem de página (com níveis do tipo order table → page tables → bitmap de páginas preservadas) — e passa o endereço físico dessa raiz diretamente no FDT. O próximo kernel apenas caminha por essa árvore, marca as áreas como reservadas no memblock e toca o boot normalmente. Resultado? Um caminho bem mais curto entre “o que preservar” e “como o próximo kernel entende isso”.
Tecnicamente, a série introduz a kho_order_table (uma raiz indexada por order), sob a qual vivem page tables intermediárias que terminam num bitmap: cada bit representa uma página preservada. Em vez de reempacotar tudo numa lista serializada, o kernel só publica um ponteiro para essa raiz no FDT e pronto. No lado que recebe, a inicialização varre a hierarquia e reserva as regiões, evitando que alocadores de early boot sobrescrevam memória que precisa atravessar o kexec.
Benefícios: mais simples, mais rápido, mais robusto
Eliminação da serialização. O gargalo de converter uma árvore xarray para um formato linear (e depois reexpandir no sucessor) desaparece. Isso economiza CPU, reduz código e remove um passo inteiro sujeito a bugs sutis.
Remoção da máquina de estados. A proposta aposenta os estados de “finalize” e “abort” que existiam só para orquestrar o empacotamento de dados antes do kexec. Sem “cerimônia” de fechamento, cai uma fonte de complexidade e de condições de corrida.
Transferência direta via FDT. Em vez de publicar estruturas temporárias, o kernel publica o que já usa internamente. O metadado de preservação passa mais perto do metal, com menos traduções — o que tende a ser mais previsível no boot seguinte.
Integração mais limpa com o memblock. Em paralelo, o memblock passa a chamar diretamente as APIs do KHO (ex.: kho_preserve_phys()), sem depender de notifiers amarrados àquela máquina de estados. Menos indireção, caminho de execução mais claro.
O que muda na prática?
Para quem constrói ou mantém sistemas com kexec frequente (clouds, NFV, infra crítica que precisa reduzir janelas de indisponibilidade), um Linux KHO stateless significa menos tempo “entre kernels” e menos superfícies onde algo pode falhar. Em termos de engenharia, é a clássica troca do “copiar e colar” por “compartilhar por referência”: você não cria um pacote intermediário; você aponta para a estrutura que já descreve a realidade.
E para quem desenvolve em cima do KHO? A vida também tende a ficar mais simples. Em vez de “esperar o finalize” para garantir que tudo foi serializado, os produtores de estado (drivers, subsistemas) marcam o que precisa ser preservado e confiam que o mapa real (a hierarquia tipo page table) chegará intacto ao outro lado.
Debate na lista: nomes, detalhes e refinamentos
Como toda mudança grande no kernel, a proposta veio em RFC justamente para colher feedback. No fio de discussão, desenvolvedores apontaram ajustes de nomenclatura (a estrutura é “page-table-like”, mas o comportamento lembra uma radix tree com bits nas folhas) e sugestões de enxugar níveis ou codificar o order de forma a compartilhar ainda mais a hierarquia. Também houve comentários práticos do tipo “já envie com a integração, evitando renomear depois”, para manter o diff limpo e o review mais objetivo. Em outras palavras: a direção — tornar o KHO stateless — parece ter boa tração, e o polimento agora é sobre a forma mais elegante de representar esse “mapa” na memória.
O que observar adiante
O status RFC indica que nada está fechado: a série ainda deve amadurecer antes de uma janela de merge futura. Mas a motivação é sólida e alinha com a trajetória recente do KHO, que foi fundido no Linux 6.16 e vem ganhando testes, documentação e casos de uso. Se você opera ambientes em que kexec é ferramenta do dia a dia, vale acompanhar e — se possível — testar: estruturas mais simples tendem a ser estruturas mais auditáveis e confiáveis.
