Perguntas, respondidas sem rodeios.

O Single Purpose OS: um sistema operacional para dispositivos dedicados, como os sistemas de controle de redes de energia e de água, terminais de salas de controle e diodos de dados de mão única, feito para a única tarefa de cada dispositivo. Você escreve a aplicação do dispositivo em Rust, e o NoWayOS a compila, só com os drivers que ela usa, sobre o microkernel seL4. A imagem contém isso e mais nada: nada de motor de navegador, sistema de janelas, shell, gerenciador de pacotes ou conta de usuário.

Um computador sem mais nada para fazer.

Um sistema operacional feito para a única tarefa de um dispositivo, em vez de ser feito para rodar qualquer coisa e depois travado numa só. Três características fazem de um sistema operacional um sistema de propósito único:

• Feito para uma só tarefa. A sua imagem contém a aplicação, os drivers que essa aplicação usa e o kernel, e nada mais: nada de navegador, área de trabalho, shell, gerenciador de pacotes ou conta de usuário.
• Isolado por dentro. Cada parte roda num compartimento próprio e só alcança o que lhe foi concedido, e tudo é projetado para que uma falha numa parte fique ali.
• Abre o jogo. Ele vem com as evidências do que há dentro e do que cada parte pode fazer: cada concessão registrada, cada componente listado e verificações que qualquer pessoa pode executar.

Um Single Purpose OS não é modo quiosque, que trava um sistema de propósito geral num único app e deixa todo o resto no lugar, nem um SO monousuário, que limita quem usa um computador, e não o que há nele. O NoWayOS é um Single Purpose OS: um computador sem mais nada para fazer.

Porque não há como explorar o que nunca foi embutido. O nome fala do que fica de fora de um dispositivo; não é uma promessa de que nada jamais possa dar errado com o que fica dentro. O que está embutido ainda pode ter bugs; as afirmações são que há muito menos disso, e que um bug fica no seu compartimento.

Travar é ser seguro por configuração: o navegador, a área de trabalho e o shell continuam lá, atrás das configurações, continuam precisando de correções, e um único bug pode contornar todas as configurações de uma vez. O NoWayOS é seguro por construção: essas partes nunca foram embutidas no dispositivo, e o que sobra roda em compartimentos isolados, com tudo projetado para que uma falha numa parte fique nessa parte.

Não. O NoWayOS está em desenvolvimento, e todas as APIs são provisórias e vão mudar. Mais de cinquenta sistemas inicializam e se verificam no QEMU, e a interface de usuário, teclado e mouse USB, temporizadores, watchdog e supervisor rodam num Raspberry Pi 5. Inicialização segura, atualizações assinadas aplicadas no dispositivo e hardware de produção ainda estão por vir.

Sim. O NoWayOS, o Showcase e o Defence Agent estão sob MIT OR Apache-2.0, à sua escolha, e o Screen Compiler é MIT. Os quatro são públicos na organização NoWayOS no GitHub: você pode clonar, compilar e abrir uma issue.

Não, e tomamos cuidado para não sugerir isso. O NoWayOS roda sobre o seL4, que tem provas de correção e segurança verificadas por máquina para configurações específicas no seu hardware. O NoWayOS usa a configuração de criticidade mista do seL4, cujas provas para AArch64 estão em andamento; por isso, hoje nenhuma imagem do NoWayOS está dentro das provas concluídas do seL4. O próprio código do NoWayOS não é coberto de forma alguma pelas provas do seL4; ele se apoia em Rust, isolamento, testes e provas limitadas próprias. Cada imagem registra a sua configuração exata do seL4 (Segurança).

Não. A segurança do NoWayOS vem do projeto, não do segredo: do que fica de fora, e dos compartimentos em volta do que fica dentro. Ser aberto permite que qualquer pessoa confira as afirmações, execute as evidências e relate o que encontrar.

Tudo é projetado para que ela fique no compartimento em que está, o que limita o estrago enquanto a correção é feita, e, com muito menos código, há muito menos correções a fazer. As correções devem chegar como atualizações assinadas com reversão segura: isso está projetado, mas ainda não construído. Para relatar uma vulnerabilidade, por favor escreva de forma privada, como descreve o SECURITY.md de cada repositório, e não numa issue pública.

Não do jeito que ela está. O NoWayOS roda aplicações escritas para ele, em Rust; ele não consegue rodar programas de Linux ou Windows, nem um web app, porque nada do que eles precisam está embutido. As telas são a parte fácil: telas React escritas dentro do subconjunto suportado pelo Screen Compiler são convertidas em Rust nativo em tempo de build. A lógica da aplicação é reconstruída como domínios de proteção do NoWayOS.

Não. Essa é justamente a ideia. Não há motor de navegador, WebView nem JavaScript num dispositivo NoWayOS. As telas são Rust nativo, desenhadas pela pequena interface de usuário do próprio NoWayOS, e ainda podem ser criadas em React e convertidas em tempo de build.

Na máquina AArch64 do QEMU, onde todo sistema inicializa primeiro, e no Raspberry Pi 5, a placa de referência de baixo custo. A família i.MX8 da NXP é o hardware de produção pretendido, com uma raiz de confiança em hardware; ela ainda não é suportada. Para compilar o NoWayOS você precisa de Podman (ou Docker) e make: ele é desenvolvido em Apple silicon, e hosts x86-64 ainda não foram testados.

Clone o repositório nowayos, execute make container uma vez e depois make demo: a sessão roteirizada da demo clicável roda na sua máquina com cada quadro verificado, sem precisar de hardware. Em seguida, make qemu-test SYSTEM=hello inicializa o seL4 no QEMU. Primeiros passos mostra o passo a passo.