Rust no kernel Linux?

https://diolinux.com.br/softwares/rust-no-kernel-linux.html

A gigante Google está apoiando uma iniciativa que visa atualizar trechos do Kernel Linux escritos em C para a linguagem Rust.

4 Curtidas

A cara se a google quer bancar as contas, seria da hora.

Pode ser bom: Conforme pontos do texto.

Pode ser ruim:

  • Dar uns bugs lokos por causa de pequenas diferenças de ABI originada pela diferença de comportamento dos compiladores gerando os objetos
  • Inserção de crates (bibliotecas) de código externo pra ser baixada em tempo de compilação
  • Pior: Inserção e pinagem de versões de crates :scream:
2 Curtidas

Acredito que toda inciativa é válida e estou vendo o rust evoluir muito.Já existe uma grande quantidade de Rust no linux no mercado. Mas gostaria de pontuar alguns tópicos do texto sobre a linguagem C:

  • C é uma linguagem antiga, mas não ultrapassada, a revisão C2x (apelido, provavelmente mudará para C23) está prevista para 2023 e a sua revisão anterior foi em 2018;
  • C é uma linguagem mais performática (por enquanto…rs) que o rust . Um dos motivos é poder utilizar assembly no seu código, coisa que vi que o rust ainda está desenvolvendo. Se não me engano chama-se “Inline assembly” na versão nightly Rust.
  • Falhas de segurança no C - Na verdade seria “Menos falhas de segurança gerada pelos programadores”. No caso o Rust seria mais fácil para se escrever um código seguro o que é diferente de estar protegido de ataques. C possuí menos abstrações e por isso demanda mais cuidados, em contrapartida, dá mais privilégios para os programadores. Já dizia tio Ben: “Com grandes poderes vêm grandes responsabilidades. O caso do buffer overflow citado acima por exemplo é gerada pela falha do programador que utilizou uma função de forma errada. Alguns exemplos:
    A função strcpy é uma função que não se deve ser usada para entrada de dados de usuários.
    Usar função strncpy sem usar um método para limpar todo garbage de memória da frase de destino. A inserção de um simples"for” ou a função memset já não causaria problemas.
    Utilizar gets onde não nenhuma verificação de tamanho onde levaria ao buffer overflow clássico (…rsrs) onde sobrescreveria o registrador EIP.

O negócio em é que Rust impede que o progamador faça " o que quiser". Mas isso faz a linguagem perder perfomance também. Por isso é complicado… C ainda é a com maior performance, e se tratando de Kernel…

E por último seria sobre a quantidade de desenvolvedores. Segundo o índice Tiobe (index | TIOBE - The Software Quality Company) no momento em que estou escrevendo, a linguagem C está em primeiro lugar.

Me desculpem o textão, mas vejo a linguagem C sendo muito subestimada recentemente. E de forma alguma estou falando que Rust não seria um boa alternativa(quem sou eu pra isso), só quis colocar alguns contrapontos para serem questionados.
Deixo aqui três pessoas como referência para caso alguém queira ver um pouco mais sobre o que mencionei acima:

Fabio souza - insta: @fabiosouza.io

Fernando Mercês - www.mentebinária.com.br

Rafael Sousa - insta: @hackingnaweboficial

5 Curtidas

Muito bem colocado! Concordo plenamente

1 Curtida

Isso não é um problema, a ABI do C é estável e padronizado e é a única ABI que pode ser usada pra expor funções escrita em Rust para o C. Se um compilador gerar um código marcado pra usar a ABI do C sem usar a ABI do C é pq tem algum bug no compilador, seja um compilador de C, Rust, Crystal ou qualquer outra linguagem que tem suporte nativo a Foreign Function Interface com C.

Isso não vai sem um problema pq o kernel não usará a ferramenta cargo para compilar os códigos em Rust dentro da arvore de desenvolvimento pelo que eu ando acompanhando. E muito provavelmente a adição de crates externas serão mínimas e com muito cuidado e não poderão ser adicionadas outras dependências on the go quando desenvolvendo um módulo dentro da árvore. As poucas bibliotecas externas serão sim baixadas, entretanto, por serem mínimas e por serem crates que são extremamente vigiadas e testadas, dos problemas, um dos menores, além delas só precisarem ser baixadas uma única vez no PC, desde que não delete a pasta que elas estão, não será necessário baixar de novo

As poucas bibliotecas externas usadas são baixadas e a versão delas não são pinadas, seguindo o mesmo modelo de versionamento semântico, se está marcado pra baixar a versão “1.0”, qualquer versão maior ou igual a 1.0 e menor que 2.0 pode ser usada pq o versionamento semântico não permite quebrar API sem mudar o numero maior da versão. Mantendo, assim, as pouquíssimas bibliotecas externas atualizadas.

Concordo parcialmente com vc, ela não é ultrapassada no sentido que ela não tem novas adições. Entretanto toda e qualquer mudança na linguagem e bibliotecas padrão devem manter compatibilidade com as versões anteriores, o que significa que não existe a possibilidade de “corrigir erros de decisão” tomados no padrão anterior.

Obs.: “Corrigir erros de decisão” no sentido que o comitê da época tomou uma decisão que não foi benéfica a longo prazo, mas pode ter sido a melhor decisão para a época. O grande problema é que muitas coisa só é possível ver as desvantagens claramente quando implementado e utilizado.

Isso está errado. A performance do Rust está par-a-par com o do C, claro que em alguns casos específicos o Rust é mais lento e em outros casos o C é o mais lento, mas no geral a diferença de performance está dentro da precisão do erro, ou seja, iguais. O Rust tem a vantagem que a sintaxe e a semântica da linguagem carregam muito mais informações que o compilador pode usar pra otimização de código, permitindo certos tipos de otimizações que não são possíveis em C padrão (C como definido pelo comitê de padronização, sem extensões de um compilador usado) e até algumas poucas que não são possíveis até em C com extensões por ser otimizações provenientes de sistema de tipos forte ou provenientes da utilização da ABI instável do Rust (o mesmo motivo que até hj o comitê do C++ não quis estabilizar a ABI do C++), entretanto o C tem a “vantagem” de não inserir nada contendo checagem em tempo de execução, como no caso de indexação de estruturas de arrays. (“Vantagem” entre aspas pq nem sempre é vantajoso fazer isso, principalmente quando se quer segurança a todo custo)

Sobre assembly: É um mito que só pelo fato de escrever em assembly algo necessariamente esse algo vai ser mais rápido que se escrito em outra linguagem, mesmo em C. Isso era verdade quando processadores eram muito mais simples e o campo de estudo de compiladores ainda não tinha tido muita inovação, numa época em que o tamanho do nome de uma variável em C afetava o tamanho e a performance do código gerado. Entretanto hoje em dia compiladores são muito mais inteligentes e muito mais capazes de gerar uma mesma função escrito em código nativo sem ser assembly extremamente otimizadas, além de linguagens assembly serem bem mais complexas (devido o aumento de complexidade dos processadores) ao ponto que praticamente nenhum humano consegue escrever um código em assembly que gere um binário tão otimizado quanto um compilador de uma linguagem com sintaxe e semântica mais ricas.
Por esses motivos, assembly basicamente só é utilizado em casos que é necessário colocar algum valor num registrador específico ou chamar alguma instrução específica que não há uma função existente que faça o mesmo (pode existir a função em um intrinsic de alguns compiladores, mas pra evitar ficar usando extensões únicas as apenas certos compiladores C e suportar mais variantes de compiladores C que não possuam esse inthinsic)

Sobre inline assembly:

  1. No C inline assembly é extensão do compilador (Faz parte do padrão do C++, mas não do C) e portanto não faz parte da linguagem em si
  2. Essa funcionalidade não é necessária pra nenhuma linguagem “baixo nível” e não afeta otimização de nenhuma forma, escrever o assembly em outro arquivo e linkar no binário final possui o mesmo efeito

Justamente pelo Rust usar técnicas que até então só eram usadas na academia, Rust escolhe pagar em outro lado no triangulo de escolha de linguagens de programação

Curiosidade: Umas das técnicas utilizadas foi aperfeiçoada ainda mais como tese de doutorado de uma pessoa que faz parte do core-team do Rust até hoje e Rust é a única linguagem que a implementa, é o que no Rust é chamado de Non-Lexical Lifetimes

Velocidade de execução, velocidade de compilação e segurança de memória → escolha dois e o que sobrou é o preço a se pagar

C escolheu velocidade de execução e velocidade de compilação
Java escolheu velocidade de compilação e segurança de memória
Rust escolheu velocidade de execução e segurança de memória

O preço que o Rust paga por ter escolhido esses dois é o tempo de compilação, que é maior que o do C, e não performance, porém parcialmente mitiga esse problema deixando o compilador paralelizado ao ponto de hoje a parte mais lenta de compilação do Rust é a única parte não paralelizada, a “linkagem” de objetos, pois ainda não existe nenhum linker paralelo que seja estável e bem estabelecido (tem um em desenvolvimento chamado mold)

De resto, concordo contigo.

Abraço a todos e tenham uma ótima semana!!

2 Curtidas

É facinho de resolver!
Só criar outro kernel em Rust e escolha usar quem quiser.
Vai ser mais rápido do que esse blá blá blá todo que esse papo tá gerando.
Parece que o povo do Linux vive num regime de ditadura que não pode fazer nada sem pedir autorização pro Linus porque ele vai deixar o cara dodóizinho e o mundo vai acabar.
Como é sabido o kernel do Linux é bugado como qualquer software que precisa suportar Deus e meio mundo.
Então, se querem algo novo e moderno, simples, só criar e deixar como escolha.
No final tudo vira binário e é uma questão de começar a usar para ficar obsoleto, inseguro e bugado.
Dai quando surgir a linguagem Shit vão querer mudar de novo.
Ou seja, o problema nunca vai ser as linguagens, mas as pessoas que usavam elas quem nao evoluiram.

2 Curtidas

Cara, fiz uma baita textão com um mínimo que eu sei e você nessa parte do comentário resumiu onde eu queria chegar!..kkkkk É exatamente isso mano perfeito

1 Curtida

@GrayJack cara, muito do que você descreveu eu nem vou ousar discutir pois foge do meu conhecimento (e agradeço porque vou pesquisar tudo isso com mais calmo). Sobre o assembly, não quis dizer do programador em si programar em assembly mas sim sobre acesso de ponteiros (…antes de mais nada vi algo sobre como funciona ponteiros no rust, mas novamente nem ouso discutir isso). No demais o ponto onde queria chegar é no trecho que o @Gilberto_Albino disse:

É extamente isso

No demais agradeço demais a discussão. Só aprendizado!

1 Curtida

Aí é que está, o próprio conceito de ponteiros é uma abstração de alto nível, no assembly não existem ponteiros, existem apenas registradores e valores fixos de memória, por esse motivo que em assuntos que se tratam de como o hardware funciona do ponto de vista do software, C é uma linguagem de alto nível.

Curiosidade: No início ponteiros era uma abstração que representava bem como o hardware funcionava, nos anos 70, quando computadores só tinham poucos registradores e memória RAM, sem caches no CPU, sem PCIe, sem o conceito de swap, sem GPU dedicada e otimizações para as mesmas. Hj em dia, um ponteiro é algo que não representa bem como o hardware funciona e portanto é uma abstração bem abstrata mesmo.

O Rust, possui os 4 tipos de ponteiros existente no C++, ponteiros finos, ponteiros gordos, ponteiros inteligentes e referências:

  • Ponteiros finos são os mesmos que o do C, e C só possui esse tipo de ponteiros
  • Ponteiros gordos são ponteiros que carregam dados a mais, um exemplo disso é o Vtable de templates/intefaces do C++ ou o Vtable de Trait Objects do Rust ou alguns tipos especiais do Rust
  • Ponteiros inteligentes são tipos definidos que funcionam como ponteiros, geralmente carregando alguma garantia a mais na forma que ele funciona, como unique_ptr do C++ ou Box, Rc, e outros do Rust
  • Referências funcionam como ponteiros finos, mas carregam informações a mais pro compilador, permitindo certos tipos de otimização. Uma referência é sempre um ponteiro válido (i.e. não nulo)

Qualquer linguagem que possui e permite usar de alguma forma ponteiros finos, seja por ponteiros finos puros ou por referências, sem subsistemas de coletores de lixoo, consegue extrair uma grande velocidade no binário final devido ao estado que está atualmente os conhecimentos e as ferramentas para criação de compiladores.

Nesse caso vc está enganado, o Linus tem poder de veto a uma adição, mas a grande maioria dos patches aceitos sequer passam pelo Linus

Não é tão simples assim, criar um kernel não é simples nem fácil, criar uma ainda com todas as features do Linux, ainda mais difícil.
Se tiver a adoção de desenvolvedores no mesmo ritmo que o Linux, provavelmente demoraria a idade do Linux hj pra terminar. E a realidade é que hj em dia a adoção é menor num ritmo menor, as chances de ter a mesmas funcionalidade logo é mínima.

O grande lance e o foco dessas linguagens de sistemas novas, como Rust e similares, não é substituir o C, e sim se integrar a C para funcionalidades novas nos projetos. Em bases de código grandes em C, cerca de 70% dos bugs são bugs de memória, entretanto a suprema maioria vem de códigos dos últimos 3 anos, as partes com mais de 5 anos já estão bem consolidadas e testadas, encontrando assim poucos bugs hj em dia, num projeto grande como o Linux isso fica ainda mais claros nos modelos estatísticos. Possibilitando usar Rust, que é uma linguagem que reforça segurança de memória, junto do C no kernel Linux, possibilita a criação de módulos novos e funcionalidades novas sem se preocupar com bugs de memória e sem a necessidade de reescrever o que está feito em C.

inclusive essa citação acima pode ser considerada errada, o projeto não visa atualizar trechos do kernel, o que está escrito, já está escrito, ela visa integrar a linguagem Rust para que novas funcionalidades, drivers e módulos possam ser criados usando Rust e obtendo mais segurança e menos bugs para estes códigos novos.

Em resumo, não faz sentido reescrever projetos grandes e bem testados como um todo em linguagens novas, não existe mão-de-obra para tal feito, além de provavelmente demorar o mesmo tanto ou mais pra chegar no estado atual dos projetos grandes. Faz muito mais sentido integrar as linguagens novas para que novas funcionalidades sejam criadas com mais segurança e facilidade.

2 Curtidas

Ótima s explicações, mas não era esse contexto. Ainda sobre ponteiros e alto nível discordo de você. Grande realidade que ainda muito se discute isso, mas meu C não é alto nível. Mas não vou prolongar mais a discussão porque está fugindo do meu ponto sobre o Assunto (por favor leia com atenção a primeira frase do meu primeiro comentário desse post). Não sou fã boy de tecnologia específica, cada qual atende uma necessidade. E se olhar coma atenção não falei mal do Rust. Pelo contrário, acho bem promissor. Só não concordei com tópicos citados pelo autor e mostrei o que não concordei. A línguagem está ai tanto tempo por algum motivo (independente de qual linguagem seja ok?). Só achei errôneo certas abordagens . Nenhuma linguagem é perfeita, mas venhamos e convenhamos que muitas “falhas” são geradas pela falha do programador e não da línguagem. Falo como exemplo (bem medíocre) não utilizar o encapsulamento em java e determinada situação e falar que isso é uma falha da linguagem. Bom, era isso Gray. Encerro por aqui pois está fugindo do ponto que quis chegar. Abrçs

1 Curtida

Concordo com seu ponto de visa, só acho precipitado algo tão verde seja colocado em algo extremamente importante como o kernel, parece atitude de estagiário emocionado.

1 Curtida

Não sei o que dizer exatamente sobre cada linguagem, mas se for por problemas que o C tem com segurança até entendo, mas porque não corrigem a linguagem C invés de inventar um Rust goela a baixo do Kernel Linux?

Não é sendo radical, acontece que quem conhece a importância do Kernel Linux não aceita essas mudanças sem se questionar o benefício real.

O que irá mudar a curto, médio e longo prazo?
Atualmente ao meu ver querem emplacar tecnologias forçando a barra em projetos como o Kernel, que apesar de ser lançado em 91 e usar uma linguagem de mais de 40 anos está em 2021 rodando liso.

É cada uma viu