Maestro: um kernel compatível com Linux em Rust

Artigo original ↗ Discussão no Hacker News ↗

Um novo sistema operacional hobbyista chamado Maestro pretende reimplementar um kernel compatível com Linux em Rust, provocando debates sobre até onde a compatibilidade no nível de syscalls pode ir sem o vasto ecossistema de drivers e as APIs instáveis no kernel das quais o Linux depende. Os comentaristas avaliam os possíveis ganhos de segurança de um kernel em grande parte seguro em memória — especialmente para isolamento de contêineres — contra a realidade de que kernels ainda precisam de bastante código `unsafe`, podem sofrer bugs de lógica e precisam interagir com hardware e firmware inseguros. O projeto também reacende argumentos de longa data sobre projetos monolíticos versus microkernels e sobre copyleft no estilo GPL versus licenciamento permissivo, com muitos vendo valor em kernels experimentais em Rust, mas duvidando que eles substituam o Linux no curto prazo.

Escopo e objetivos do projeto

  • Maestro é um SO hobbyista que começou como uma tarefa escolar: um kernel monolítico de 32 bits, compatível com syscalls do Linux, escrito em Rust.
  • O objetivo é прежде de tudo educacional; qualquer adoção externa é um bônus.
  • Atualmente implementa cerca de um terço das syscalls do Linux, mas inicializa o suficiente para executar bash e está perto de rodar ferramentas como vim e compiladores.
  • Usa drivers clássicos de hardware (VGA, PS/2, IDE/ATA); comentaristas sugerem mirar VMs e virtio como um próximo passo prático.
  • A compatibilidade completa com aplicativos Linux é vista como algo para anos à frente, principalmente por causa de syscalls complexas, da pilha TTY e do enorme ecossistema de drivers.

Rust, segurança de memória e segurança

  • Muitos veem um kernel em Rust como uma grande redução de risco: menos bugs de memória, melhor isolamento de regiões unsafe e exploração mais difícil (anedotas de tentativas de exploração em Rust usadas como apoio).
  • Outros enfatizam “mais seguro em memória”, não “seguro em memória”: kernel e drivers ainda precisam de unsafe, e bugs de lógica, configurações incorretas, problemas de hardware e firmware continuam sendo vetores de ataque importantes.
  • Debate em torno de contêineres: alguns argumentam que bugs de memória no kernel são o principal motivo pelo qual contêineres não podem ser uma fronteira forte; outros dizem que a maioria dos escapes de contêiner no mundo real vem de erros de configuração e da superfície mais ampla do kernel, não apenas de erros de memória.
  • Microkernels (por exemplo, seL4) e verificação formal são discutidos como caminhos alternativos ou complementares para garantias mais fortes.

Drivers, estabilidade de ABI e reuso

  • Há consenso de que drivers são a parte mais difícil do trabalho de SO.
  • A ABI de espaço de usuário do Linux é altamente estável; sua ABI de drivers no kernel é intencionalmente instável para facilitar a evolução interna e desencorajar drivers fechados, tornando irrealista a compatibilidade entre módulos de diferentes kernels.
  • Sugestões para Maestro: focar em um pequeno conjunto de hardware ou VMs, reutilizar via rump kernels, ou até mesmo executar Linux em uma VM para os drivers ausentes.

Debates de arquitetura e design

  • Alguns gostariam que Maestro seguisse um microkernel ou uma arquitetura mais radical; outros observam que combinar “Rust + compatibilidade com Linux” já é experimentação suficiente.
  • Um grande subthread discute escrever kernels em assembly de RISC-V para evitar a “complexidade” de linguagem/compilador; a maioria dos respondentes considera isso impraticável, impossível de manter e não significativamente mais seguro ou portátil.

Discussões sobre licenciamento

  • Maestro é licenciado sob MIT.
  • Um grupo alerta que isso convida forks proprietários e “trabalho gratuito para futuras corporações”, argumentando que GPL (ou AGPL) preserva melhor as liberdades do usuário e ajudou a tornar o Linux bem-sucedido.
  • Outros contrapõem que licenças permissivas também viabilizam ecossistemas comunitários vibrantes, que a GPL não garante bom comportamento e que os usuários não perdem nada se forks proprietários coexistirem com o original.
  • Alguns sugerem espelhar a GPLv2 do Linux para facilitar o compartilhamento de código e evitar debates intermináveis sobre licenças.