Durante uma apresentação no RustWeek 2026 em Utrecht, o mantenedor da linha estável do kernel Linux, Greg Kroah-Hartman, levantou uma ideia que chamou a atenção de toda a comunidade: uma nova proposta baseada em Rust poderia eliminar até 80% das CVEs (vulnerabilidades conhecidas) do Linux kernel.
A afirmação não é leve. Ela vem de alguém que, há anos, acompanha praticamente todas as falhas de segurança reportadas no kernel. E o ponto central da discussão não é uma mudança de forma de pensar sobre um problema antigo: como o kernel lida com dados não confiáveis.
O ponto cego do C
Grande parte do código do kernel é escrita em C, uma linguagem extremamente poderosa, mas que não impõe certas garantias de segurança em tempo de compilação. O problema destacado por Greg é simples de entender, mas difícil de resolver historicamente: o kernel constantemente recebe dados de fora, seja do espaço do usuário, seja de hardware. Esses dados não deveriam ser confiáveis em nenhum momento.
Em teoria, isso sempre foi conhecido. Na prática, porém, o C não oferece um mecanismo nativo para marcar esses dados como “não confiáveis”. Uma vez que eles entram no kernel, viram apenas ponteiros comuns, podendo circular livremente entre funções sem que o contexto original seja preservado.
Isso abre espaço para erros sutis: validações esquecidas, usos indevidos e caminhos de execução onde verificações importantes simplesmente não acontecem.
O que o Rust já resolve hoje
Antes mesmo da nova proposta, o uso de Rust no kernel já vem mostrando impacto. Dois tipos de falhas aparecem com frequência em CVEs do kernel: esquecer de checar retornos de erro e falhar ao liberar travas (locks). Em Rust, esses problemas são tratados diretamente pelo compilador, o que reduz drasticamente a chance de ocorrência.
Segundo estimativas apresentadas por Greg, só essas duas categorias podem representar cerca de 60% dos bugs encontrados no kernel.
Além disso, o simples processo de criar bindings em Rust para código em C já forçou revisões mais rigorosas de APIs antigas. Conceitos como propriedade de memória, regras de bloqueio e imutabilidade passaram a ser explicitamente documentados, algo que antes muitas vezes ficava implícito.
O ponto mais interessante da apresentação é uma proposta em desenvolvimento: um novo tipo chamado Untrusted, criado em conjunto com o contribuinte Benno Lossin.
Nela, qualquer dado vindo de fora do kernel, como usuário ou hardware, seria automaticamente marcado como “não confiável” através desse tipo. Isso não adiciona custo em tempo de execução, é uma marcação feita em tempo de compilação.
Dessa forma, esse dado não pode ser usado livremente. Ele não pode ser acessado como um valor comum sem passar por uma etapa explícita de validação. Só depois dessa validação ele se torna “confiável” e pode ser usado em lógica crítica.
Isso muda um comportamento histórico do kernel: em vez de depender da disciplina dos desenvolvedores para validar dados no lugar certo, o próprio sistema de tipos passa a forçar essa separação.
Um ponto importante é que isso centraliza validações. Em vez de checks espalhados pelo código, existe um ponto claro onde a transição de “não confiável” para “confiável” acontece.
O que isso muda
Na visão apresentada, boa parte dos CVEs atuais não surgiria simplesmente porque o tipo de erro que os causa deixaria de ser possível. Hoje, muitos problemas acontecem quando dados externos são tratados como internos cedo demais, ou quando passam por caminhos onde a validação não acontece.
Com Untrusted, isso se torna mais difícil de acontecer por acidente. O código precisa explicitamente “assumir a responsabilidade” por aquele dado antes de usá-lo.
Há também um segundo efeito menos óbvio: o hardware também entra nessa equação. O kernel historicamente foi construído assumindo que hardware é confiável, mas isso vem mudando. Dispositivos maliciosos ou comprometidos já são uma realidade, e o mesmo modelo de “dados não confiáveis” se aplica aqui.
Apesar do entusiasmo, essa mudança ainda não foi incorporada ao kernel principal. A implementação depende de ajustes no compilador Rust e de outras melhorias no ecossistema, como suporte a projeções de campos e integração com o modelo de tipos do kernel.
Mesmo assim, o caminho já está sendo trilhado. O código base inicial do Untrusted já existe no repositório do kernel, servindo como prova de conceito de como essa ideia pode funcionar na prática.
Ajude o Diolinux a permanecer independente e crescente: seja membro Diolinux Play e tenha acesso a benefícios exclusivos.