- Um kernel compatível com a ABI do Linux escrito em Rust, que busca combinar as vantagens dos kernels monolíticos e dos microkernels ao aplicar a arquitetura de “framekernel”
- Projetado para encapsular todo o código unsafe dentro de bibliotecas limitadas, permitindo que o restante dos serviços do kernel seja desenvolvido com abstrações seguras em Rust, alcançando ao mesmo tempo segurança de memória e uma estrutura simples de memória compartilhada
- O que o diferencia de outros sistemas operacionais em Rust, como RedLeaf, Tock e Rust for Linux, é o suporte a isolamento por hardware, foco em uso geral, ABI compatível com Linux e execução de espaço de usuário em várias linguagens
- Busca minimizar a TCB (base computacional confiável) e avançar em verificação formal (com uso de Verus), além de oferecer suporte a hardware de execução confiável como Intel TDX e também frameworks de desenvolvimento de SO como OSTD/OSDK
- Ainda está em estágio inicial de desenvolvimento: suporta x86/RISC-V e implementa 206 system calls, com foco em ambientes Docker/contêineres/cloud, mas também tenta expandir para desktop com X11/Xfce
O que é Asterinas?
- Asterinas é um novo projeto de kernel compatível com a ABI do Linux, desenvolvido em Rust
- A arquitetura de “framekernel” limita o código Rust
unsafe (trechos inseguros de memória) a bibliotecas de framework, envolvendo-o com APIs seguras, enquanto o restante dos serviços do kernel é desenvolvido inteiramente em Rust seguro
- O objetivo é buscar ao mesmo tempo a estrutura simples e de alto desempenho de um kernel monolítico e a minimização da TCB (base computacional confiável) e a segurança de um microkernel
- Dentro do kernel, os serviços operam separados no mesmo espaço de endereçamento, e cada serviço só pode usar os recursos concedidos pela biblioteca central
Explicação da arquitetura framekernel
- O conceito de framekernel foi proposto pela primeira vez no artigo "Framekernel: A Safe and Efficient Kernel Architecture via Rust-based Intra-kernel Privilege Separation"
- Um kernel monolítico coloca todo o código em um único espaço de endereçamento em modo kernel, enquanto um microkernel reserva o espaço do kernel apenas para a TCB mínima e delega a maior parte das funções a serviços em modo usuário
- O framekernel encapsula em bibliotecas o código que exige o uso de
unsafe em Rust, e desenvolve o restante dos serviços do kernel com abstrações Rust seguras em termos de memória
- Cada serviço roda dentro do espaço de endereçamento do kernel, mas é limitado a acessar apenas os recursos explicitamente fornecidos pela biblioteca
- Manter uma TCB pequena torna a verificação formal (prova matemática) mais viável, além de aumentar a confiabilidade e a estabilidade do sistema como um todo
- É uma abordagem que combina memória compartilhada (alto desempenho, como em kernels monolíticos) com separação interna de privilégios e segurança (vantagens dos microkernels)
Comparação com sistemas em Rust existentes e com o framekernel
- RedLeaf: microkernel baseado em Rust, sem uso de isolamento por hardware
- Asterinas: SO de propósito geral, usa isolamento por hardware, é compatível com a ABI do Linux e oferece suporte à execução de espaço de usuário em várias linguagens
- Tock: voltado para SoCs embarcados, separa o núcleo (com
unsafe permitido) das cápsulas (código seguro), mas não oferece suporte a isolamento por hardware
- O projeto Rust for Linux também tem como objetivo envolver interfaces do kernel com abstrações seguras, para permitir que drivers do kernel sejam escritos com segurança em Rust
Verificação formal e segurança
- O principal objetivo de reduzir a TCB é tornar a verificação formal realisticamente viável
- O Asterinas é o único caso que busca simultaneamente uma TCB pequena e verificável, como a do seL4, compatibilidade com a ABI do Linux e uma estrutura baseada em memória compartilhada
- Em colaboração com a empresa especializada em auditoria de segurança CertiK, o projeto está realizando trabalho de verificação formal com base em Verus
- O relatório de avaliação de segurança da CertiK divulga os pontos auditados e os problemas encontrados no projeto
Bibliotecas e ferramentas de desenvolvimento
- Além do próprio kernel, o projeto oferece OSTD (framework de SO em Rust) e OSDK (ferramenta de desenvolvimento baseada em Cargo)
- Principais objetivos do OSTD:
- Reduzir a barreira de entrada no desenvolvimento de SO e criar base para inovação
- Reforçar a segurança de memória em sistemas operacionais Rust e abstrair APIs de baixo nível
- Incentivar a reutilização de código entre projetos de SO em Rust
- Permitir testar novo código em modo usuário (aumentando a produtividade no desenvolvimento)
- Kernels baseados em OSD e OSTD não precisam ser compatíveis com Linux, e fornecem APIs seguras de alto nível para controle de hardware x86, memória virtual, multiprocessamento (SMP), timers etc.
- A Intel participa como patrocinadora, em especial pela afinidade com tecnologias ligadas a Trust Domain Extensions (TDX) e isolamento de máquinas virtuais
Situação do desenvolvimento e principais patrocinadores
- Foi lançado pela primeira vez como open source (licença MPL) no início de 2024; atualmente tem 45 contribuidores, com principais contribuições vindas de doutorandos da SUSTech, Universidade de Pequim, Universidade Fudan e da Ant Group, na China
- Suporta x86 e RISC-V, com 206 system calls do Linux implementadas (de um total de 368)
- Ainda não consegue executar aplicativos, mas tem como meta desenvolver uma distribuição inicial e suporte a contêineres (Docker), além de tentar abordagens como distribuição baseada em Nix
- Não oferece suporte ao carregamento de módulos do kernel Linux e não há plano de adotá-lo permanentemente
Planos futuros
- No curto prazo, define como prioridade ampliar o suporte a mais arquiteturas de CPU e mais hardware, além de melhorar a usabilidade real em ambientes de cloud
- O suporte a dispositivos Linux virtio foi concluído, e o principal alvo é o mercado de cloud chinês (Alibaba Cloud, Aliyun)
- O objetivo central é desenvolver um host OS para contêineres com TCB segura e reduzida, além de suporte a recursos de computação confiável da Intel
- Embora tenha propósito semelhante ao do Rust for Linux, este se limita a introduzir Rust em drivers dentro do kernel existente, enquanto o Asterinas busca um novo design de kernel completo e a minimização da TCB
- No momento, também há experimentos em várias direções, como suporte a X11 e Xfce, e o próprio OSTD pode ter potencial para atrair a atenção de desenvolvedores de SO em geral
Diferenças em relação ao Rust for Linux
- Rust for Linux: introduz apenas drivers seguros em Rust no kernel Linux existente; o kernel como um todo continua baseado em C
- Asterinas: implementa um novo kernel do zero em Rust, limita rigorosamente o
unsafe, avança em verificação formal e foca em ambientes de cloud/contêineres
Visão geral e perspectivas
- O Asterinas tenta uma abordagem inovadora em segurança de memória, verificação formal e aplicabilidade prática em ambientes de cloud
- Ainda não há exemplos de uso prático nem validação ampla da comunidade, mas o projeto vem atraindo interesse nas áreas de pesquisa em SO, cloud e segurança
- Frameworks como o OSTD podem ter utilidade futura no ecossistema de desenvolvimento de SOs em Rust
Resumo dos principais pontos dos comentários no LWN sobre o Asterinas
- Singularity OS e o debate sobre fronteiras de segurança baseadas em linguagem
- O framekernel do Asterinas é semelhante ao Singularity OS da Microsoft, mas usa o borrow checker do Rust para aumentar a segurança de memória
- Sobre a abordagem de proteger sistemas com fronteiras de segurança da própria linguagem (por exemplo, Rust, Java, WASM/JS), há o confronto entre a crítica de que "confiança total é impossível e, na prática, isso é usado junto com sandbox em nível de hardware/SO" e a visão de que "há vantagens na prevenção de falhas e na verificação formal"
- WASM, JS e Java também geram debate sobre segurança, mas em serviços reais não costumam ser considerados confiáveis apenas com sandbox de linguagem; na prática, é comum combiná-los obrigatoriamente com sandboxes de hardware ou do SO
- Tendências no desenvolvimento de sistemas operacionais e contexto geopolítico
- Nos últimos anos, surgiram vários novos projetos de SO, ampliando o clima de inovação na área
- A China está acelerando o desenvolvimento de sistemas alternativos ao Linux em resposta a sanções tecnológicas dos EUA e a riscos na cadeia de suprimentos
- Continuam intensos os debates políticos sobre sanções dos EUA, governança global do open source sob a GPL e a necessidade de países como China e Europa buscarem ecossistemas tecnológicos independentes
- A dificuldade de manter um fork do Linux versus desenvolver um kernel totalmente novo, a dependência do conhecimento e know-how da comunidade e a barreira linguística também aparecem como temas de debate
- Debate sobre compatibilidade com Linux e número de system calls
- Muitos opinam que medir compatibilidade pelo número de system calls do Linux é inadequado
- Como uma única system call (
ioctl, por exemplo) pode embutir inúmeras APIs detalhadas, para avaliar compatibilidade real é mais importante executar aplicativos de verdade e usar suítes de teste do kernel
- Também aparece a visão pragmática de que, assim como o Linux inicialmente foi implementando system calls uma a uma para obter compatibilidade POSIX, suportar 99% das principais system calls já pode permitir a execução de bastante software
- Licença e ecossistema Rust
- Discussão sobre a escolha da MPL pelo Asterinas: há opiniões positivas de que a MPL combina bem com o ecossistema de crates do Rust e com licenciamento modular
- Há também a visão de que a GPL nem sempre é a melhor opção e que, com apoio corporativo, pode fazer sentido usar uma licença mais amigável a empresas, como a MPL
- Dependências do projeto e segurança
- Questiona-se se é seguro usar muitos crates externos em um SO baseado em Rust, e surge a necessidade de automação de segurança e auditoria da cadeia de suprimentos com ferramentas como cargo deny/vet
- Menciona-se também que, na prática, apenas o lockfile não basta para entender a superfície de dependências, dadas as dependências transitivas e dependências por SO típicas do ecossistema Rust
- Inspirações técnicas e arquiteturas semelhantes
- Aponta-se que o conceito de framekernel se parece com a arquitetura do SPIN OS da University of Washington nos anos 1990
- O SPIN também enfatizava forte modularidade e controle de interface/acesso por meio do compilador
- Discussão sobre a composição dos committers
- Foi mencionado que, entre os 45 contribuidores, muitos commits se concentram em um pequeno grupo de doutorandos
- Também houve a observação de que é um equívoco considerar contribuições lideradas por estudantes de PhD como menos valiosas, já que o projeto tem significado como iniciativa inovadora orientada à pesquisa
- Debates políticos/históricos e alertas de off-topic
- A discussão sobre sistemas operacionais se expandiu para debates geopolíticos, políticos e históricos envolvendo EUA, Europa e China, levando editores a emitir vários alertas de "off-topic"
- Alguns usuários destacaram que o ecossistema open source/FOSS também pode ser afetado por mudanças no ambiente geopolítico
- Outros
- Compartilhamento de artigos acadêmicos sobre a segurança do WASM
- Mistura de avaliações positivas e críticas sobre o andamento do desenvolvimento do kernel
2 comentários
Gostei bastante desse tipo de iniciativa.
Fico pensando se em breve veremos um kernel que não morre.
Comentários do Hacker News
Acho que é uma abordagem interessante e torço para que dê certo. Mas ainda continuo com dúvidas. Ainda lembro do que o Linus disse sobre concorrentes numa entrevista de TV no fim dos anos 90 ou começo dos anos 2000. Ele falou algo na linha de: "ninguém gosta de escrever drivers; estamos seguros até aparecer algum jovem faminto que se torne um excelente engenheiro de drivers". Já naquela época ele reconhecia que manter a interface de drivers instável era uma espécie de mecanismo de defesa. Passados 25 anos, kernels rodando sobre hardware virtualizado são extremamente comuns, mas ainda dá para contar nos dedos os sistemas operacionais realmente práticos e utilizáveis que conseguiram abstrair o hardware real com sucesso
Sobre a parte de que "manter a interface de drivers instável é uma defesa", acho que no futuro pode surgir um jovem pesquisador de sistemas, ou uma IA, e que agentes de IA possam traduzir drivers Linux em C para drivers Asterinas seguros em Rust. Outra abordagem prática é reutilizar o próprio kernel Linux dentro de algum ambiente isolado. Por exemplo, o kernel HongMeng reutiliza drivers com User-Mode Linux. O Asterinas também poderia aplicar uma estratégia parecida. Referência: https://www.usenix.org/conference/osdi24/presentation/chen-haibo
Tenho dúvidas de que o Linus realmente quisesse ou tivesse a intenção de criar uma "barreira defensiva". Ele não é fundador de startup de tecnologia; originalmente era só um hacker de kernel, e já garantiu há muito tempo o sustento para o resto da vida. Interpretar a instabilidade da interface de drivers dentro do kernel como uma estratégia deliberada para impedir concorrência parece projeção demais
Já houve precedentes como SPIN OS (Modula 3), JX OS (Java), House OS (Haskell) e Verve. Todos implementaram funcionalidades de kernel usando linguagens type-safe e memory-safe. Em geral, a estrutura escondia operações perigosas atrás de chamadas de função verificadas; alguns também usavam VM. Tirando questões de desempenho e adoção, as principais fragilidades são falhas nas abstrações, desvios via código unsafe, colapso do modelo de segurança por compilador/JIT e falhas gerais de hardware (por exemplo, raios cósmicos em espaçonaves). Ainda assim, é muito mais seguro do que kernels/apps em linguagens unsafe. Para ir além, seria possível usar análise estática de código unsafe, garantir que todas as funções unsafe obedeçam a interfaces type- e memory-safe, usar compiladores que preservem a segurança das abstrações na integração e também compiladores certificados por componente. A maior parte das ferramentas de produtividade já existe; só falta uma delas, a "compilação com abstração totalmente segura", que ainda está em pesquisa, embora inspeção manual também seja possível
Há um motivo para dar para contar nos dedos os sistemas operacionais realmente utilizáveis. O mundo do hardware está cheio de "padrões" de interface, mas na prática quase nenhum hardware se comporta exatamente conforme o padrão. Sem o tempo necessário para escrever código de driver que lide com todas as peculiaridades e defeitos irremediáveis (errata), é realmente difícil ter desempenho e suporte em hardware físico real
Por outro lado, 98% do Linux com que lido na prática roda em ambientes virtualizados. No desktop/laptop, uso Virtualbox em tela cheia; drivers para Windows só quando realmente preciso; no Mac, uma VM headless gerenciada pelo Docker.app. Todas as cargas operacionais da empresa rodam em VMs da AWS. O único hardware Linux que uso em casa também é um home server, e em breve pretendo substituí-lo por uma VM de Mac mini comprada no eBay. Se surgir um kernel compatível com Linux, mais seguro e com desempenho parecido, hoje em dia é fácil escolher uma alternativa mesmo que faltem drivers
Ouvi dizer que microkernels mais recentes melhoraram bastante os problemas de desempenho de IPC. Não lembro exatamente o quanto melhorou, mas acho que o trauma da indústria com Mach foi grande. Pelo site do projeto, a estrutura parece ser a de que apenas o Framework (modo privilegiado) pode usar
unsafeem Rust, enquanto os Services (não privilegiados) usam apenas Rust seguro. Isso soa meio estranho: se o código não privilegiado for unsafe, ele não continua sendo perigoso mesmo assim? Já o lado que realmente exige verificação de código unsafe pode usá-lo sem restrições? E, olhando a licença, o Asterinas usa principalmente Mozilla Public License (MPL) 2.0, com alguns componentes sob licenças mais permissivas. Não é GPL nem BSD, parece algo no meio-termoSobre a pergunta de que "é estranho o código não privilegiado unsafe ser perigoso, enquanto o código que realmente precisa de verificação fica concentrado no lado privilegiado", isso precisa ser interpretado no contexto de framekernel. O framekernel inteiro baseado em Rust roda no espaço de kernel, mas logicamente é dividido em duas partes: um framework de SO privilegiado e serviços de SO não privilegiados. A parte privilegiada inclui tanto código de kernel Rust safe quanto unsafe; a parte não privilegiada inclui apenas código de kernel Rust safe. Essa política se aplica inteiramente a código de kernel. Em framekernels, não há restrição sobre a linguagem dos programas de usuário
Pelo que sei, microkernels recentes em geral melhoraram drasticamente o desempenho de IPC. O exemplo mais conhecido é o seL4, que otimiza IPC de forma extremamente agressiva, a ponto de o IPC ser muito mais rápido do que syscalls típicas do Linux. A maioria dos programas comuns provavelmente rodaria até mais rápido em seL4. Gostaria de ver dados reais comparando desempenho
É verdade que microkernels modernos melhoraram a questão de IPC. Na realidade, o problema mais fundamental é que, em hardware moderno, até syscalls de kernels monolíticos são muito lentas. É por isso que interfaces como
io_uringevirtiotêm bom desempenho: elas processam requisições e respostas em filas entre sistema e app (ou entre hipervisor e guest), evitando troca de espaço de endereçamento. Os sistemas operacionais do futuro, qualquer que seja a arquitetura, vão precisar de mecanismos de syscall baseados em filas. E, adotando esse modelo, já não há grande diferença de desempenho entre SOs monolíticos, microkernels ou outras estruturasNo framekernel, a separação privileged/unprivileged não significa kernel/user space. O sistema operacional inteiro roda no nível de privilégio do kernel. Mas, logicamente, ele se divide entre código de biblioteca central (uso de unsafe permitido, privileged) e o restante do código de componentes do kernel (usa a biblioteca, mas não pode usar unsafe diretamente, unprivileged). Provavelmente isso é imposto por verificações estáticas, como linter. É uma estrutura fácil de confundir por causa da sobreposição de termos
Como tarefas não privilegiadas também rodam no mesmo espaço de memória do núcleo do kernel, não há como impedir em runtime comportamentos inseguros. Para separar privilégios em runtime de verdade, seria necessária uma arquitetura de microkernel. Aqui, o privilégio é implementado estaticamente, e não em runtime, proibindo código unsafe
Fico me perguntando se esse conceito de separar o kernel em um pequeno núcleo unsafe e grandes módulos safe é realmente uma tentativa nova. Acho interessante e promissor como projeto, porque evita o overhead de hardware dos microkernels, escapa dos problemas de segurança dos monolíticos e aproveita bem a distinção entre safe/unsafe da linguagem de sistemas
Isso me lembrou o texto review de Rust in Linux por Drew DeVault. Também dá para ligar à discussão no HN https://news.ycombinator.com/item?id=41404733
Acho uma tentativa realmente impressionante, e também é bacana que o autor esteja nesta thread. Fico curioso para saber até que ponto isso já é utilizável; gostaria de montar uma imagem de servidor e testar, nem que seja em algum ambiente limitado
Ao ver a explicação de que microkernel IPC é lento e por isso tem pouca popularidade, fico aliviado ao perceber que até gente tecnicamente brilhante parece entender errado os motivos da adoção real e o processo por trás disso
A licença é MPL e, pessoalmente, acho que existem licenças melhores (como GPLv3)
Acho uma ideia realmente boa. Já existe muito software construído, e ter uma base alternativa pode trazer grandes vantagens e opções também por motivos não técnicos. Isso me faz lembrar de kFreeBSD e GNU/Hurd
Fico pensando como deveríamos chamar esses kernels. *nux?