A maioria dos sistemas operacionais modernos é construída sobre décadas de código acumulado, bibliotecas e dependências externas. Embora esse ecossistema permita desenvolvimento rápido, ele também introduz complexidade, pressupostos ocultos e riscos de segurança potencialmente não examinados.

O EriX adota uma abordagem diferente.

Ele é desenvolvido como um sistema operacional de sala limpa, o que significa que cada componente - do bootloader aos serviços em espaço de usuário - é implementado dentro do próprio projeto, sem incorporar código-fonte externo ou bibliotecas de terceiros.

Este artigo explora o que o desenvolvimento de sala limpa significa na prática, por que ele é útil e quais concessões ele introduz.

O que significa “sala limpa”?⌗

No contexto do EriX, desenvolvimento de sala limpa significa:

  • Nenhum código-fonte externo é copiado ou reutilizado
  • Nenhuma biblioteca ou crate de terceiros é incluída
  • Todos os componentes são implementados dentro do projeto
  • Apenas especificações e documentação públicas podem ser consultadas

O resultado é um sistema em que cada linha de código é:

  • compreendida
  • auditável
  • projetada intencionalmente

Essa não é apenas uma decisão legal ou de licenciamento; é uma decisão arquitetural.

Por que evitar código externo?⌗

Evitar dependências externas pode parecer restritivo. O desenvolvimento moderno de software normalmente incentiva reutilização, e grandes ecossistemas existem precisamente para evitar reinventar a roda.

No entanto, sistemas operacionais não são aplicações típicas.

1. Complexidade oculta⌗

Código externo frequentemente traz pressupostos implícitos:

  • sobre o layout de memória
  • sobre modelos de concorrência
  • sobre tratamento de erros
  • sobre o comportamento da plataforma

Esses pressupostos podem não se alinhar à arquitetura de um novo sistema operacional, especialmente um construído em torno de capacidades e isolamento estrito.

2. Base de computação confiável (TCB) ampliada⌗

Cada dependência aumenta o tamanho da base de computação confiável.

Se uma biblioteca de terceiros é usada no kernel ou em componentes críticos do sistema, sua correção passa a fazer parte das garantias de segurança do sistema.

O desenvolvimento de sala limpa mantém a TCB:

  • pequena
  • controlada
  • explicitamente definida

3. Auditabilidade e verificação⌗

Um sistema construído inteiramente internamente pode ser auditado sistematicamente.

  • Todo código unsafe pode ser revisado
  • Todos os invariantes podem ser documentados
  • Todas as interfaces podem ser analisadas

Isso é especialmente importante para um sistema como o EriX, que enfatiza:

  • autoridade explícita
  • segurança baseada em capacidades
  • design mínimo do kernel

4. Liberdade arquitetural⌗

Reutilizar código existente frequentemente restringe decisões de design.

Por exemplo:

  • adotar uma biblioteca pode impor uma forma específica de API
  • integrar código existente pode exigir camadas de compatibilidade
  • abstrações legadas podem vazar para novos componentes

O desenvolvimento de sala limpa permite que o sistema seja moldado inteiramente por seus próprios princípios, em vez de por restrições herdadas.

Sala limpa vs. reimplementação⌗

É importante distinguir desenvolvimento de sala limpa de simples reimplementação.

Desenvolvimento de sala limpa não significa reescrever cegamente sistemas existentes.

Em vez disso, ele envolve:

  • estudar especificações públicas
  • compreender princípios subjacentes
  • projetar novas implementações a partir de primeiros princípios

Por exemplo:

  • Um sistema de arquivos pode seguir a semântica POSIX, mas ser implementado de forma independente
  • Um bootloader pode seguir as especificações UEFI, mas usar uma estrutura personalizada
  • Uma biblioteca padrão C pode expor a mesma API, mas ser escrita inteiramente em Rust

O objetivo é compatibilidade onde necessário, sem reutilização de código.

Sala limpa na prática⌗

No EriX, as restrições de sala limpa são aplicadas em todo o sistema.

Sem crates externos⌗

Mesmo em Rust, onde reutilização de dependências é comum, o EriX evita crates externos.

Em vez disso, ele define componentes reutilizáveis internos, como:

  • utilitários de memória
  • primitivas de sincronização
  • abstrações de capacidades

Bibliotecas internas⌗

Funcionalidade reutilizável é organizada em crates internos, por exemplo:

  • lib-bootimg
  • lib-capabi
  • lib-ipc

Essas bibliotecas são:

  • versionadas
  • controladas dentro do projeto
  • projetadas especificamente para as necessidades do sistema

Estrutura rígida do repositório⌗

Cada subsistema é isolado:

  • bootloader
  • kernel
  • IPC
  • gerenciamento de memória
  • serviços em espaço de usuário

Isso impõe modularidade e evita acoplamento oculto.

Builds reproduzíveis⌗

O design de sala limpa se estende ao processo de build.

O sistema busca:

  • builds determinísticos
  • pressupostos mínimos sobre a cadeia de ferramentas
  • etapas de build explícitas

Isso garante que artefatos possam ser reproduzidos e verificados.

Benefícios de um sistema operacional de sala limpa⌗

1. Compreensão completa do sistema⌗

Cada componente é conhecido e compreendido.

Não há dependências opacas nem comportamentos ocultos.

2. Modelo de segurança mais forte⌗

Com uma TCB menor e controlada:

  • existem menos superfícies de ataque
  • invariantes são mais fáceis de impor
  • segurança baseada em capacidades pode ser implementada de forma limpa

3. Melhor plataforma de pesquisa⌗

O EriX não é apenas um sistema operacional; ele também é uma plataforma de pesquisa.

O desenvolvimento de sala limpa permite:

  • experimentação com novas abstrações
  • medição precisa de concessões de design
  • raciocínio claro sobre autoridade e isolamento

4. Manutenibilidade de longo prazo⌗

Embora inicialmente exijam mais trabalho, sistemas de sala limpa podem ser mais fáceis de manter:

  • sem quebras de dependências
  • sem mudanças upstream para acompanhar
  • sem conflitos de versão

O sistema evolui em seus próprios termos.

Concessões e desafios⌗

O desenvolvimento de sala limpa não vem sem custo.

1. Desenvolvimento mais lento⌗

Tudo deve ser construído do zero:

  • bibliotecas básicas
  • suporte de runtime
  • serviços do sistema

Isso aumenta significativamente o esforço inicial.

2. Reinventar a roda⌗

Muitos problemas já foram resolvidos em outros lugares.

Reimplementá-los exige tempo e design cuidadoso.

3. Menos atalhos⌗

Não há possibilidade de:

  • importar rapidamente uma biblioteca
  • depender de ecossistemas existentes
  • delegar complexidade a código externo

Toda a complexidade deve ser tratada diretamente.

4. Maior responsabilidade de design⌗

Cada abstração deve ser projetada deliberadamente.

Erros não podem ser facilmente encobertos pela troca de dependências.

Por que essa abordagem se encaixa no EriX⌗

O EriX é construído em torno de alguns princípios centrais:

  • base de computação confiável mínima
  • autoridade explícita por meio de capacidades
  • separação estrita entre kernel e espaço de usuário
  • reprodutibilidade e determinismo

O desenvolvimento de sala limpa apoia todos esses objetivos.

Ele garante que:

  • a autoridade nunca fique escondida dentro de código externo
  • os invariantes do sistema sejam totalmente controlados
  • a arquitetura permaneça consistente em todos os componentes

Uma base para self-hosting⌗

O design de sala limpa também apoia o objetivo de longo prazo de self-hosting.

Para construir o EriX dentro do EriX, o sistema deve incluir:

  • sua própria cadeia de ferramentas
  • suas próprias bibliotecas de runtime
  • suas próprias interfaces de sistema

Um sistema que depende fortemente de componentes externos teria dificuldade para alcançar esse nível de independência.

Olhando adiante⌗

Projetar um sistema operacional de sala limpa é um esforço de longo prazo. Ele exige planejamento cuidadoso, implementação disciplinada e disposição para construir componentes fundamentais do zero.

Mas também cria um sistema que é:

  • transparente
  • controlado
  • profundamente compreendido

Em artigos futuros, passaremos dos princípios para a implementação, começando pelo processo inicial de boot e pelo design do formato de imagem de boot do sistema.