Rust Agora é Oficial no Kernel do Linux — e a Segurança de Memória Está se Tornando uma Política de Segurança

A melhoria de segurança mais impactante da história da computação pode não ser um novo esquema de autenticação, um firewall mais inteligente ou um sistema de detecção melhor. Pode ser a mudança na linguagem de programação com a qual os sistemas operacionais são escritos.

Vulnerabilidades de segurança de memória — bugs de uso após liberação, estouros de buffer, desreferências de ponteiro nulo, estouros de inteiro que se tornam estouros de buffer — são responsáveis por aproximadamente 70% dos CVEs de alta gravidade da Microsoft há anos. O Google relata números semelhantes para Chrome e Android. A NSA publicou uma orientação afirmando que cerca de 70% de todas as vulnerabilidades de software exploráveis são problemas de segurança de memória. Não são casos extremos obscuros — são a classe mais comum de vulnerabilidade explorável, e são comuns há quarenta anos porque a maior parte do código dos sistemas operacionais é escrito em C e C++, linguagens que facilitam a escrita de código inseguro em relação à memória e dificultam a detecção de bugs até que algo quebre em produção.

Rust elimina toda essa categoria. Não adicionando um coletor de lixo em tempo de execução — Go e Java adotam essa abordagem, e isso custa desempenho que os sistemas operacionais não podem arcar. Em vez disso, Rust usa um verificador de empréstimos (borrow checker) em tempo de compilação que rastreia a propriedade e os tempos de vida de cada pedaço de memória durante a construção. Se você escrever código que poderia produzir um bug de uso após liberação, o compilador Rust se recusa a compilá-lo. O erro de memória não ocorre em tempo de execução. Ele falha em tempo de compilação com uma mensagem de erro informando exatamente o que está errado. Sem crash, sem CVE, sem ciclo de patches, sem hotfix de emergência enviado às 3 da manhã.

O Marco do Kernel Linux

O kernel Linux é a base do Android, da maior parte da infraestrutura em nuvem e de uma vasta gama de sistemas embarcados. Também é escrito quase inteiramente em C — cerca de 27 milhões de linhas acumuladas ao longo de trinta anos. Adicionar uma nova linguagem de programação a uma base de código tão antiga e crítica é uma decisão que leva anos de validação antes de se tornar política oficial.

O primeiro código Rust foi mesclado ao kernel Linux com o lançamento 6.8 em dezembro de 2023. As implementações iniciais cobriram o driver GPU Asahi (suportando Macs Apple M1 e M2 rodando Linux) e alguma infraestrutura de driver NVMe — áreas onde novos desenvolvimentos estavam ocorrendo e onde o risco de quebrar a funcionalidade existente era minimizado. Isso foi uma prova de conceito de que Rust poderia operar dentro das restrições rigorosas do kernel e coexistir com a base de código C existente.

Em dezembro de 2025, o projeto do kernel Linux declarou oficialmente que o Rust no kernel não é mais experimental. O desenvolvimento do kernel em Rust agora é parte oficial do processo de desenvolvimento do kernel, com as mesmas garantias de estabilidade, requisitos de teste e padrões de revisão de código que o desenvolvimento em C. Novos subsistemas do kernel podem ser escritos em Rust com a confiança de que Rust permanecerá como uma linguagem suportada do kernel a longo prazo — um compromisso que anteriormente não podia ser feito porque a designação experimental significava que a infraestrutura Rust do kernel poderia ser removida se não funcionasse.

Isso é importante na prática por várias razões. Desenvolvedores de drivers podem escrever novos drivers em Rust sem incerteza sobre se a infraestrutura Rust do kernel existirá na próxima versão do kernel. Componentes críticos de segurança do kernel — pilhas de rede, drivers de sistema de arquivos, subsistemas criptográficos — podem ser sistematicamente reescritos em Rust ao longo do tempo, reduzindo a superfície de ataque de código que atualmente roda com privilégios de anel 0 e processa entrada externa não confiável. E sinaliza para a comunidade mais ampla de programação de sistemas que Rust é uma escolha séria de longo prazo para trabalho no kernel, o que afeta decisões de contratação, treinamento e investimento em ferramentas em toda a indústria.

Adoção do Rust pelo Android e Resultados

O Google começou a adicionar Rust ao Android em 2021 e tem sido o mais transparente em medir os resultados. Em 2024, o Google relatou que aproximadamente 77% do novo código do Android é escrito em Rust — um número que reflete o novo código sendo adicionado à plataforma, não a base de código existente em C e C++, que permanece em grande parte como foi escrita e continua sendo mantida.

O impacto mensurável na segurança é significativo. A taxa de vulnerabilidades de segurança de memória descobertas no Android diminuiu ano após ano desde 2019, o mesmo período em que a adoção do Rust começou. O Google atribui isso diretamente à escolha da linguagem: o código Rust rodando no Android não produz CVEs de segurança de memória na mesma taxa que o código C, porque o compilador impede toda a classe de bugs antes que o código seja enviado.

A pilha Bluetooth do Android, partes da pilha de rede e componentes da infraestrutura de codecs de mídia foram reescritos em Rust. Estas são exatamente as superfícies de ataque que historicamente produziram vulnerabilidades de alta gravidade — elas processam entrada externa não confiável (pacotes de pareamento Bluetooth, dados de rede, arquivos de vídeo de fontes não confiáveis) com lógica de análise complexa onde um único erro de off-by-one pode se tornar uma vulnerabilidade de execução remota de código explorável sem interação do usuário.

Abordagem da Microsoft

A adoção de linguagens seguras para memória pela Microsoft está distribuída em várias iniciativas, em vez de uma única determinação centralizada. A equipe do kernel do Windows tem avaliado Rust para o desenvolvimento de novos drivers de kernel, e a Microsoft contribui ativamente para o projeto Rust for Windows, que fornece bindings Rust para APIs do Windows. A infraestrutura do Azure adotou Rust em vários componentes. O projeto Hyperlight da Microsoft — um hipervisor leve projetado para executar funções serverless em escala — foi construído em Rust desde o início.

Mais amplamente, a Microsoft se comprometeu a escrever novos códigos críticos de segurança em linguagens seguras para memória (que incluem Rust, Go e C#, juntamente com as linguagens seguras mais antigas Swift e Java) e a reescrever sistematicamente o código C e C++ existente em alternativas seguras para memória onde o risco de segurança justifica o custo de engenharia. Isso não é uma determinação de "reescrever tudo em Rust" — é uma abordagem priorizada por risco que foca as reescritas seguras para memória em código que lida com entrada externa e é executado com privilégios elevados, que é exatamente onde bugs de memória se transformam em vulnerabilidades exploráveis.

Os Desafios Reais

As garantias de segurança de memória do Rust vêm com verdadeiras compensações que importam para a adoção no mundo real:

A curva de aprendizado é íngreme. O borrow checker impõe regras de propriedade que parecem estranhas para desenvolvedores vindos de C, C++ ou da maioria das outras linguagens. "Lutar contra o borrow checker" é uma frustração comum para desenvolvedores novos em Rust. O Google estima que leva de seis meses a um ano para um desenvolvedor C experiente se tornar genuinamente produtivo em Rust em uma base de código grande. Em escala, isso é um investimento significativo em treinamento e recrutamento.

A interoperabilidade com C é necessária, mas complexa. Qualquer estratégia de migração realista envolve Rust chamando C e C chamando Rust — cruzando a fronteira FFI entre as duas linguagens. Essa fronteira requer blocos unsafe em Rust, que podem introduzir os mesmos bugs de memória que Rust previne. Acertar as fronteiras FFI requer engenharia cuidadosa, e cada bloco unsafe precisa de revisão minuciosa.

Os tempos de compilação são mais longos. A análise do borrow checker é computacionalmente cara. Grandes bases de código Rust compilam significativamente mais devagar do que bases de código C equivalentes, o que afeta a velocidade de iteração do desenvolvedor e os tempos de pipeline de CI/CD. Este é um problema conhecido que a equipe Rust está trabalhando ativamente, mas ainda é um custo real.

A base de código existente não vai desaparecer rapidamente. O kernel Linux tem 27 milhões de linhas de C. Mover isso incrementalmente para Rust levará muitos anos, e o código C existente continuará produzindo vulnerabilidades de segurança de memória durante toda essa transição. A mudança para linguagens seguras para memória é estrutural e geracional — ela previne novas vulnerabilidades em novo código, não bugs existentes em código existente.

A Dimensão Política

O desenvolvimento mais significativo recente não é um marco técnico — é a mudança de recomendação técnica para política de segurança. A CISA, a NSA e seus equivalentes do Five Eyes publicaram todas orientações formais afirmando que os desenvolvedores de software têm a responsabilidade de usar linguagens seguras para memória para novos códigos críticos de segurança. A Estratégia Nacional de Cibersegurança da Casa Branca menciona a segurança de memória explicitamente. Esse enquadramento muda a equação para organizações que escrevem software que lida com dados sensíveis ou infraestrutura crítica.

Não é mais puramente uma decisão técnica. É uma questão de saber se uma organização pode defender suas escolhas de linguagem perante reguladores, auditores e clientes. A combinação de maturidade técnica — as ferramentas, ecossistema e documentação do Rust melhoraram dramaticamente desde 2021 — e pressão política formal está acelerando a adoção além do que apenas o caso técnico impulsionaria.

A segurança de memória é um problema resolvido na teoria das linguagens de programação. Torná-la o padrão prático na infraestrutura de sistemas operacionais é um projeto de engenharia geracional. O marco do kernel Linux, as métricas de adoção do Android e a mudança política indicam que esse projeto passou de exercício acadêmico para realidade de engenharia — lentamente, com arestas, e em uma escala de tempo medida em décadas, não em ciclos de produto. A direção é clara e o momentum é real.