 |
Rust no kernel Linux: A guerra sem trégua |
Em 2023 eu escrevi o artigo Rust no Linux: Um caso de amor e ódio e depois dessa nova temporada de Rust no kernel, eu estava pensando em fazer um vídeo porém, como ando muito ocupado, preferi escrever aqui no blog mesmo.
Bom, a treta de Rust no kernel Linux continua. Tentaram de todas as formas e contra todos os gostos promover Rust no kernel Linux, houve resistência por parte de muitos desenvolvedores e até mesmo de Linus Torvalds mas por fim, foi feita a adoção. Depois disso houveram novos problemas, o principal responsável por Rust no kernel saiu do projeto e em Fevereiro desse ano, começou o processo tudo de novo; ninguém dá trégua nessa bagaça. Muitos desenvolvedores não apoiam sua adoção mas a cartada final dada por Greeg Kroah-Hartman:
"Adicionar outra linguagem não deveria ser um problema, já lidamos com coisas muito piores no passado."
"Sim, bases de códigos de linguagens mistas são grosseiras e difíceis de manter, mas somos desenvolvedores de kernel, droga. A gente vem mantendo e fortalecendo o Linux por mais tempo que qualquer um já pensou que fosse possível"
Não tem como discordar do Gregg nesse ponto já que nós sysadmins passamos bastante por situações parecidas, mas alguns até mesmo abandonaram o desenvolvimento como Karol Herbst que deixou o desenvolvimento do driver nouveau depois que adotaram o driver Nova como substituto do Nouveau; Christoph Hellwig bateu de frente com todos (inclusive com Linus) e esse debate parece não tem fim.
Estamos em um período de transição na tecnologia onde novos processadores, novos chips e novas linguagens estão surgindo. Muito se fala hoje em dia sobre segurança de memória (apesar que este assunto já dura mais de 30 anos) e seus benefícios; Em 2017 foram reportados cerca 40 CVEs somente do kernel Linux relacionados a falhas de segurança de memória. Então, se for para o bem, sim eu acredito que uma linguagem que possua recursos relacionados a segurança de memória deva ser adotada no desenvolvimento do Linux, mas Rust não é esta linguagem; outras linguagens são muito mais interessantes para se integrar ao kernel Linux do que Rust, como é o caso de Lua e Nim. Bom, o argumento que podem apresentar é que Lua é uma linguagem interpretada por scripts. Sim, porém o NetBSD possui drivers escritos em Lua, o carregador de boot do FreeBSD é escrito em Lua e o interpretador do rpm é escrito em Lua:
Lua é uma linguagem que facilmente se comunica com a linguagem C e C se comunica com tudo; geralmente é comum incorporar códigos C a alguma aplicação Lua para se comunicar com outras coisas. Lua na verdade já nasceu tendo como uma de suas características ser amigável com a linguagem C; inclusive um dos melhores recursos da linguagem Lua é exatamente o design de sua API que lhe permite integrar seu código a bibliotecas C ou fazer com que scripts Lua sejam executados de forma muito rápida junto ao código C dos jogos. Alias, se precisar portar seu código Lua para C, se torna uma tarefa muito mais fácil do que qualquer outra linguagem. E SIM, LUA POSSUI SUPORTE A SEGURANÇA DE MEMÓRIA!
Eu conheci Lua por volta de 2007 ou 2008 em um PDF como uma linguagem para integrar a linguagem C e fazer coisas que a linguagem C não faz; depois eu descobri que Lua já era amplamente utilizada em muitas aplicações como desenvolvimento da maioria dos jogos (inclusive liderando a parte de scripts de jogos e já até ganhou prêmios na parte de jogos), aplicações industriais, estações espaciais e petrolíferas, sistemas embarcados, os sites Wikipedia e Github são implementados em Lua, Netflix faz forte uso de Lua, Adobe Photoshop Lightroom, Ultradefrag, VLC, nmap, wireshark (1, 2), snort (1, 2), Metaplace, teclados da Logitech. Lua é um grande caso de sucesso e mais presente do que imaginamos sem essa necessidade de propaganda e comoção que foi feito em cima de Rust.
Nim é outra linguagem muito mais apropriada e interessante para o kernel Linux (existem ao menos dois sistemas operacionais escritos em Nim) e seus recursos únicos, que eu vou descrever mais a frente, são muito mais interessantes do que Rust.
Muitos projetos se beneficiarão de Rust enquanto que muitos outros não; alias, é uma lei natural. Exemplos reais são o Android que se beneficiou de Rust tendo redução de 76% para 24% de seus bugs enquanto que o port do fish shell de C++ para Rust não resultou em nenhum benefício, não entregou nenhum novo recurso e quando estes surgiram, não estavam vinculados a linguagem Rust... já outros projetos por outro lado, pode ser tornar até prejuízo a adoção de Rust tanto que há programas ques estão sendo migrados de Rust para outras linguagens como é o caso do gerenciador de pacotes da distribuição Glaucus Linux que foi portado de Rust para Nim (sintax mais simples e mais fácil de manter, melhor desempenho e menos uso de memória, de CPU) e a linguagem Roc que está sendo reescrita de Rust para Zig pela sua eficiência no processo de compilação ser maior e ter menos dependências (1; 2. Valeu Nilton por compartilhar estas informações). É questão do que se adéqua ou não a necessidade (aprendam isso). Honestamente, esta terceira opção é a mais provável que venha acontecer com o kernel Linux. Sim, eu vejo isso acontecer.
Não é de hoje que tentam substituir a linguagem C como menciona o próprio autor da linguagem C Plus Prolog (ou simplesmente C+P) que descreve sobre a linguagem C como sendo a única linguagem útil* (*portável, com desempenho que mais se aproxima de Assembly e consegue se comunicar com tudo) e que cientistas vem tentando há quase 50 anos encontrar uma solução para (digamos) substituir a linguagem C. E alguns até criaram C mais parecida com a linguagem Prolog e outros criaram o inverso, Prolog parecido com C."
O grande problema não é a linguagem Rust, o problema é mais uma questão psicológica. Os usuários estão querendo adotar Rust de forma eufórica e irracional, sem pesar na balança as vantagens e desvantagens assim como todas as linguagens possuem, sem pensar nas consequências; só estão querendo adotar acreditando que Rust é a oitava maravilha do mundo que solucionará todos os problemas da humanidade. A maioria não são desenvolvedores e os que são, além de nunca nem mesmo terem explorado o real potencial da linguagem C, estão cheios de amores por Rust... Rob Landley, autor do toybox que eu sempre menciono, disse em seu artigo de 21/09/2024 da melhor forma:
"Eu desisti de Rust porque todo puritano de Rust que eu encontro há anos trata NÃO escrever código em Rust como um pecado... ...A multidão "all must rust away" não conseguem explicar as vantagens de Rust a não ser "não é C"...
A única coisa que vemos é essa frescura de "rewrite in Rust", o que é uma bela de uma burrice já que o kernel Linux possui quase 1 Gigabyte somente de código na linguagem C. Levariam vários anos só para porta-lo para Rust e mais muitos outros anos somente para torna-lo estável (reescrever drivers será uma mão de obra intensa e que introduzirá mais problemas do que soluções — reescritas sempre introduzem bugs). Por vezes eu já vi desenvolvedores sugerir aos desenvolvedores de Rust desenvolverem as mesmas soluções do zero ao invés de ficarem querendo reescrever tudo em Rust. O autor da linguagem Hare sugeriu:
"Um grupo motivado de talentosos desenvolvedores de sistema operacional em Rust poderiam construir muito rápido um kernel compatível como Linux do zero e sem necessidade de se envolverem na política LKML"...
"Eu acho que se o montante de esforços sendo colocados no Rust-for-Linux fossem aplicados em um novo sistema operacional compatível com Linux, poderíamos ter algo pronto para produção para alguns casos de uso dentro de alguns anos."
..."desenvolver um sistema operacional baseado em um design comprovado como o do Linux é muito mais fácil e pode ser feito muito rápido. Eu trabalho em meu próprio sistema operacional de novo design (um microkernel) há alguns anos e ainda está travado no design e precisa urgentemente ser repensado; por outro lado eu escrevi um clone aceitável do Unix em menos de 30 dias."
O MIT também já desenvolveu um kernel assim chamando Biscuit o e apresentou no Usenix de 2018. Biscuit é kernel monolítico POSIX escrito na linguagem Go e é tão compatível com Linux que roda as aplicações do próprio Linux sem nenhuma necessidade de modificação do código fonte das aplicações. Por que a galera de Rust não acata essa proposta? Outro grande exemplo de escrever algum programa do zero e não de porta-lo é o bzip2; no meu artigo Qual o futuro do Bzip2? descrevi que os novos mantenedores foram questionados se portariam bzip2 para Rust, o que foi respondido que eles preferem trabalhar no suporte a multithreading em C, que para Micah é algo que seria muito interessante principalmente nas futuras versões 1.2 ou 2.0, do que qualquer coisa em Rust (lembram-se que eu mencionei que muitos que estão cheios de amores por Rust nunca nem mesmo exploraram o real potencial da linguagem C? Aqui está uma prova disso) e por fim foi indicada a implementação do Bzip2 em Rust desenvolvida do zero.
Lanldey também argumenta sobre o desenvolvimento de um sistema operacional escrito em Rust do zero e ainda apresenta a percepção das intenções da comunidade Rust:
"Se quizerem escrever um novo sistema operacional inteiramente em Rust, com kernel e userspace e toolchain, tudo em Rust, eu respeitaria isso e desejaria tudo de bom para eles. Mas não é o que eles querem. eles acreditam que lhes é devido Linux e eles querem sequestrar Linux (ainda que majoritariamente escrito em C)"... ..."E eles acreditam que ADICIONAR COMPLEXIDADE ADICIONAL resultará em sistemas melhores"
Sim, essa é percepção que se passa; não é que querem ter uma linguagem secundária no kernel Linux com a intenção de melhorar sua segurança e sim de aos poucos dominar o kernel substituindo todo o código por Rust para se autopromover. Rescrever algo em Rust pode se tornar uma cilada; imaginem a complexidade será reescrever o código rust para outra linguagem; você pode acabar ficando atrelado a ela (coincidência ou não, já vi desenvolvedores reclamando de coisas parecidas do projeto GNU).
O que esquecem de nós contar é exatamente os contras da linguagem: Curva de aprendizado terrível; difícil de debugar; complexa (não é a toa que o autor do minibase diz que o Rust coreutils o forneceu uma grande inspiração por lhe mostrar como não escrever o coreutils); tempo de compilação enorme; ecossistema pequeno; otimizada para a maioria dos processadores i686 e x86_64 porém, em outras plataformas como armel, armhf, armv7, mips{64}, powerpc{64} e riscv{64} carece de suporte de primeira classe, fora "recursos" de Rust que podem causar erros e bugs no LLVM; utilizar HLL pode causar perdas de desempenho, uso excessivo de CPU, memória e I/O; foram o tamanho dos biários ser enorme.
 |
| Diferença de tamanho dos binários UUtils e toybox |
.jpg)
Se gabam unicamente de segurança de memória sem mencionar à que custo... E tudo tem um custo. O artigo The benefits and costs of writing a POSIX kernel in a high-level language faz uma ótima análise descrevendo os benefícios de escrever seus programas e sistemas operacionais em linguagens com segurança de memória ao custo de sacrificar o desempenho que foi de 5% a 15%. Segurança de memória pode também afetar os seus programas; o autor da linguagem C3 descreve em seu artigo Por que eu parei tudo e comcei a escrever em C de novo:
"...Quem consegue escrever um jogo de estratégia com milhares de units cada tendo sua própria versão de mundo sem ter um garbage collector rodando o inferno? De fato meu amigo tentou escrever o jogo e falhou. Garbage collectors são péssimos e todos os meu projetos em Lisp possuem aplicações muito limitadas apenas por causa do garbage collector. ..."
Ok, o segundo argumento que podem querer apresentar é que Rust não utiliza garbage-collection por acreditarem não ser um recurso eficiente. Ao invés disso, Rust aplica a técnica de analisar o código fonte durante o processo de compilação para garantir que não haja brechas de segurança; PORÉM este tipo de recurso já é empregado na linguagem C há muito, mas muito tempo. A biblioteca dietlibc emprega ao menos seis linker warnings (avisos) durante o processo de compilação para ajudar os desenvolvedores escrever melhores códigos:
- Avisa se assert for utilizado (pode indicar debug code)
- Avisa se stdio for utilizado (bloat)
- Avisa se sprintf for utilizado e indica utilizar snprintf por ser melhor e mais seguro¹
- Avisa se *printf/*scanf for utilizado (bloat e recomenda utilizar -lowfat)
- Avisa se system for utilizado (risco de segurança)
- Avisa se mktemp/tempnam/tmpnam for utilizado (race condition)
E esse é um dos grandes problemas; Rich Felker, autor da biblioteca musl, descreveu em seu artigo intitulado Overcommit que "há um monte de mal entendidos relacionados a gerenciamento de memória no Linux que levam à um monte de programas ruins que falham de forma robusta com condições de baixa memória e geram mitos". OK, gerenciamento de memória e segurança em memória são coisas diferentes, mas a mesma situação se aplica-se a ambos os casos, ou seja, não vai adiantar nada adotar outra linguagem se os desenvolvedores não souberem tratar corretamente seus códigos.
Falando em musl, além de também fazer a mesma coisa por trabalhar com o conceito de quality safe code (visando ser correta no senso conformidades padrões e segurança) é utilizada para encontrar bugs através do recurso fail-safe da biblioteca.
A Red hat adicionou a flag -FORTIFY_SOURCE aos compiladores GCC e Clang para detectar falhas como buffer over flow (1). O GCC também possui desde 1998 a extensão StackGuard que é uma Stack Smashing Protection (SSP) (1) que ajuda o compilador detectar e prevenir ataques buffer-overflow que alias, o OpenBSD faz forte usso deste recurso.
O compilador tinycc possui a opção -b (bounds checker) há no mínimo 15 anos... E o GCC há uns 10... foram o recursos ASan (AddressSanitizer) que é um plugin detector de erros de memória para C/C++ utilizado inclusive no Google Chrome do Android, no Chrome OS, simulador do iOS, Linux, Mac, e Windows de 64 bits e disponível no LLVM há mais ou menos uns 15 anos (1, 2, 3), -fstack-protector, -fsanitize=safe-stack, UBSan (-fsanitize=bounds) e o SafeCode. Alias, a própria Wiki do ASan sugere o uso da ferramenta como cgroups para limitar o consumo de memória. Por que não incluir Pledge a esta lista? Ou seja, existem vários mecanismos para se utilizar somente com a linguagem C, mas a solução que encontraram foi adotar outra linguagem que pode gerar uma série de outros problemas... ... ... Enquanto isso Rust possui um recurso chamado unsafe que a galera de rust se refere como o "segredinho sujo" que eles utilizam em todos os lugares mas está tudo bem... São eles que estão usando... não é?
Está certo que utilizar recursos como verificação do código fonte acaba gerando binários um pouco maiores por acabar adicionando mecanismos de segurança, mas em Rust isso tinha que ser tão exagerado? O Rust coreutils por exemplo, contendo apenas apenas 87 comandos e sendo linkado dinamicamente, possui o tamanho de mais de 12MB enquanto o toybox, sendo linkado estaticamente e contendo 233 comandos (quase três vezes mais que o Rust Coreutils), ocupa apenas 724KB (mais de 17 vezes menor levando em conta sua ligação estática e a quantidade de comandos). Já houve quem dissese que isso acontecem em Rust apenas em X86 por conta das dependências e não ocorre em embarcados. O que não é verdade pois geralmente Rust gera binários praticamente do mesmo tamanho.
O interessante mesmo é poder decidir quando utilizar segurança de memória. No livro Nim in action descreve que algumas linguagens de programação, como C, não possuem segurança de memória porque ela permite que programas sem atribuição possa acessar a memória. Por outro lado, linguagens possuem segurança de memória oferecem essa segurança ao custo de não permitir que programas acessem detalhes de baixo nível da memória quando se faz necessário; e é aí que Nim se torna uma linguagem muito interessante. Por padrão Nim já oferece proteção contra erros de memória porém, porém Nim oferece as duas opções (escrever códigos com ou sem segurança de memória) permitindo que você decida quando utilizar cada uma delas. Ainda no livro Nim in Action descreve que "...há situações quando muitos querem evitar garbage collectors; eles são considerados por muitos ser inadequados para certas aplicações como embarcados e jogos. Por essa razão, Nim possui suporte a um número diferente de garbage collectors com diferentes aplicações em mente. Garbage collector pode também ser removido completamente, lhe dando a habilidade de você mesmo gerenciar memória." ... "Aplicações escritas em Nim são muito rápidas, em muitos casos, tão rápidas quanto aplicações escritas em C, e mais de trinta vezes mais rápido do que aplicações escritas em Python. Eficiência é maior prioridade, e alguns recursos toram otimização de código fácil. Isso vai de mãos dadas com um soft real-time garbage collector, que lhe permite especificar o montante de tempo que deve ser gasto coletando memória. Esse recurso se torna importante durante desenvolvimento de jogos, onde um garbage collector comum pode desacelerar a renderização de frames na tela se utilizar muito tempo coletando memória. Também é útil em sistemas real-time que precisam rodar em frames de tempo muito estrito." Nim, além de por padrão já proteger seu programa contra todos os tipos de erro de memória, possui também recursos muito mais interessantes como meta programação, style intensitivity; seu type system (que apesar de ser estática, incorpora o recurso type inference que lhe permite acelerar o desenvolvimento do seu código sem sacrificar a segurança), type safety e type-checking dinâmico; Generics (que lhe permite reutilizar o código sem sacrificar type safety) e muito mais.
(13/08/2025) Linguagens como C e C++ possui suporte a segurança em memória, mas algo que é feito manualmente. Os desenvolvedores que devem verificar seus próprios códigos e identificar o problema (algo que já vimos aqui Rich Felker denunciando). Os desenvolvedores do Busybox por exemplo fazem isso muit bem, no dia 03/08/2025, Denys Vlasenko corrigiu o vazamento de memória causado pela otimização do compilador.
(13/08/2025) Além destes recursos, a equipe do Btrfs implementou no dia 12/08/2025 o ref_tracker que detecta vazamentos e printa os traços da pilha que ainda não liberadas e assim poderem corrigir os problemas.
Vale ressaltar que essas técnicas de memory safety também são possíveis na linguagem C e C++ não somente manualmente como muitos acreditam mas também através de garbage collector para C e C++ que foi desenvolvido pelos três pesquisadores Hans-J. Boehm, Demers e Weiser (por isso o nome bdwgc) em meados da década de 90... Este recurso lhe permite utilizar garbage collector nas duas linguagens quando quiser bastabdo definir #include "gc.h" em seu código. O bdwgc também oferece o recurso Leak Detector.
(28/03/2025) No dia 26 de Fevereiro de 2025 a equipe de desenvolvedores do XFS implementou o recurso garbage collection no zoned do XFS todo desenvolvido em C (e que vai para o kernel 6.15-rc). E no dia 19 de Março foi adicionado a opção gc_pressure no mount do XFS para evitar um risco no garbage collection em circunstancias distintas. O que nos leva a questionar se realmente se faz necessário a adoção de uma linguagem secundária no kernel Linux somente pelo recurso de segurança em memória ao custo de perda de desempenho, binários enormes, alto consumo de memória, CPU e etc sendo que tal recurso já está presente de tantas formas (linguagens mais adequadas, algoritmos, bibliotecas, flags, extensões), há tanto tempo (uns há quase trinta anos) e que já poderiam estar sendo empregados...
 |
Garbage Collection no zoned do XFS
|
E o mais interessante de tudo: Se lembram do artigo da Casa promovendo que todos deveriam migrar de linguagens como C e C++ para linguagens com segurança de memória? Pois é, estranhamente parece que a Casa Branca voltou atrás e não vai mais promover segurança de memória já que o mesmo link está indisponível.
Bom, eu acho que agora sim neste segundo artigo eu tenha abordado elementos o suficiente para pensar no assunto; o assunto de segurança em memória vai muito além do que simplesmente adotar uma linguagem com tal recurso achanado que solucionará os problemas de forma definitiva.
.jpg "V coreutils: Um coreutils escrito na linguagem V")
.png "Vinix: Um sistema operacional escrito na linguagem V")
.jpg "processo de compilação do V coreutils")
.jpg)
.jpg)
.jpeg)
.jpg)
![pode ocorrer de alguns programas não compilarem (como o glibc) por que eles dependem de extensões específicas do GCC (é por isso que todo o código do BSD pode ser compilado com o LLVM mas alguns códigos GNU não) [nota do redator: liberdade?] ou padrões depois de compilação com sucesso do LLVM (como o xorg-server) ... ... Os frontends do C/C++ do LLVM, clang and clang++ na versão 3.0 são estáveis o suficiente para ser self-hosting compilar Boost, Qt, LibreOffice, FreeBSD, algumas partes do kernel Linux kernel e muito mais.](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjZJtSczVFcSlqpweUVyGsybNhVjUK8NLeDhecPkxgPZI3yAibw1HvAjxOvtISw2d-g99Yd60GZGEk1Z5soDl9dtxXXYc5RDmw0ZVI-UfEFGzFVa3o8Xu0NbB5JjSFtRXiRhXy6pKJZ_qA/s1600/clangOnFuntooLinuxDocumentation.png "pode ocorrer de alguns programas não compilarem (como o glibc) por que eles dependem de extensões específicas do GCC (é por isso que todo o código do BSD pode ser compilado com o LLVM mas alguns códigos GNU não) [nota do redator: liberdade?] ou padrões depois de compilação com sucesso do LLVM (como o xorg-server) ... ... Os frontends do C/C++ do LLVM, clang and clang++ na versão 3.0 são estáveis o suficiente para ser self-hosting compilar Boost, Qt, LibreOffice, FreeBSD, algumas partes do kernel Linux kernel e muito mais.")
