O Diário do NoWayOS

Entra React, sai Rust

2026-11-13T00:00:00Z

As interfaces modernas são projetadas em React. Por isso, muitíssimos dispositivos dedicados, de painéis de controle a máquinas de bilhetes, levam um motor de navegador inteiro, um dos maiores e mais atacados programas que existem, para desenhar alguns botões e as palavras “Touch Start to begin”.

Queríamos o fluxo de design moderno sem o navegador. Então construímos o Screen Compiler.

Escreva a tela em React

Os seus designers e desenvolvedores de front-end continuam com as suas ferramentas: componentes, props, design tokens, o editor deles. Eles escrevem a tela em TSX (esta foi abreviada de uma das telas de teste do Screen Compiler):

<Column gap={SPACE_SM} padding={SPACE_LG}>
  <Text id="title">Welcome</Text>
  <Text>Touch Start to begin.</Text>
  <Spacer />
  <Button id="start" onPress={onStart}>Start</Button>
</Column>

Entregue Rust puro e simples

Em tempo de build, na sua máquina ou na CI, o Screen Compiler transforma isso em Rust para o runtime de interface do NoWayOS:

let n1 = b.text("Welcome")?; // welcome.tsx:17:9 <Text>
let n2 = b.text("Touch Start to begin.")?; // welcome.tsx:18:9 <Text>
let n4 = b.spacer(None)?; // welcome.tsx:20:9 <Spacer>
let n5 = b.button("Start", actions::START)?; // welcome.tsx:21:9 <Button>

Cada linha aponta de volta para o TSX de onde veio. O dispositivo recebe esse código e mais nada: sem motor de JavaScript, sem navegador, sem página web para atacar. O próprio Screen Compiler nunca vai para o dispositivo.

Exato, ou nada

Um conversor que adivinha é um conversor em que não se pode confiar. O Screen Compiler converte com exatidão o seu subconjunto declarado de TSX e recusa todo o resto, informando o arquivo, a linha e a coluna. Ele nunca aproxima. O Rust que ele escreve não tem unsafe, nem unwrap, nem panic.

Depois, cada tela convertida é desenhada pelo renderizador do NoWayOS e comparada, pixel a pixel, com a sua imagem aprovada. Se um único pixel se mover, o build avisa.

Em que pé está

O Screen Compiler está em desenvolvimento: o seu primeiro subconjunto está construído e o próximo está em andamento. Ele é open source sob a licença MIT, no GitHub ao lado do NoWayOS. Se a sua equipe projeta em React e constrói dispositivos que importam, gostaríamos de ouvir você.

O backup que não era uma cópia

2026-11-13T00:00:00Z

Todo mundo sabe que é bom ter um backup. Menos gente faz a pergunta incômoda que vem depois: um backup de quê, exatamente?

Cinco alarmes

Em 20 de julho de 1969, o módulo lunar da Apollo 11 estava a poucos minutos da superfície da Lua quando o seu computador de guiagem disparou um alarme sobre o qual a tripulação precisou perguntar ao controle da missão. Depois outro. Cinco ao todo, no trecho final da descida.

O computador estava sobrecarregado. O que ele fez em seguida é uma das grandes obras de engenharia dessa história: a cada vez, ele reiniciou, largou o trabalho que podia esperar e retomou na hora o trabalho que não podia. O pouso continuou.

Essa é a parte que todos contam. A parte que vale contar em seguida aconteceu no dia seguinte.

O segundo sistema

O módulo lunar levava um segundo sistema de guiagem, e ele não era uma cópia reserva do primeiro. Outra empresa o construiu, sobre outro princípio. O sistema principal mantinha a orientação com uma plataforma que girava livremente sobre cardãs. O segundo não tinha cardãs: os seus sensores eram parafusados diretamente na nave, e ele descobria onde ficava o alto fazendo contas.

Ele estava lá para levar a tripulação de volta à órbita se o sistema principal algum dia parasse. Durante o pouso, não foi chamado.

Então, na subida para acoplar ao módulo de comando, uma sequência de manobras levou a plataforma do sistema principal à única posição com que uma plataforma com cardãs não consegue lidar, e ele perdeu a sua referência de atitude. A tripulação passou para o segundo sistema para manter a nave estável, e acoplou.

O segundo sistema não poderia ter falhado do mesmo jeito. Ele não tinha a peça.

Dois iguais

Agora a outra história. Em 1996, o primeiro Ariane 5 decolou com duas unidades de referência inercial para lhe dizer para onde estava apontando: uma em operação, outra de prontidão. Eram idênticas, até no software.

Aos trinta e sete segundos, um número dentro desse software ficou grande demais para o espaço reservado a ele. A unidade de prontidão parou. A unidade em operação, rodando o mesmo código no mesmo voo, parou também. O relatório da comissão de inquérito é público, e é direto: não havia para o que mudar, porque o backup já tinha ido pelo mesmo caminho.

Duas cópias. Uma falha. Nada sobrou.

Como os engenheiros chamam isso

Uma falha que derruba um sistema e o seu reserva juntos é uma falha de causa comum. A defesa contra ela é a redundância diversa: um segundo sistema construído de forma diferente o bastante para que aquilo que para o primeiro não esteja no segundo.

O ônibus espacial voava assim. Quatro dos seus computadores de voo rodavam o software de uma empresa; o quinto rodava software escrito separadamente por outra. Quatro cópias protegem você de um computador que quebra. Não protegem de um programa que está errado, porque os quatro o estão rodando.

Isso não sai de graça. O primeiro lançamento do ônibus espacial foi cancelado quando o quinto computador e os outros quatro não conseguiram concordar sobre a hora. Dois projetos dão mais trabalho do que um, e é preciso fazer com que se encontrem.

Onde o NoWayOS entra

A maioria dos dispositivos dedicados roda hoje um de um número muito pequeno de sistemas operacionais de uso geral. Os backups deles também. Quando aparece um defeito em um motor de navegador, em uma área de trabalho ou em um kernel de dezenas de milhões de linhas, ou quando sai uma atualização ruim, ele aparece em todo lugar em que esse software roda, no mesmo dia.

Um dispositivo NoWayOS é diferente por dentro. O seu kernel é o seL4, cerca de 10.000 linhas. Tudo o que é nosso acima dele é escrito em Rust. Ele não tem motor de navegador, área de trabalho nem shell, então um defeito em um deles não está nele.

Isso quer dizer que o NoWayOS não precisa substituir o que você já opera para ser útil. Ele pode ficar ao lado: uma segunda forma de fazer uma tarefa essencial, construída sobre outro princípio.

O que ele não faz

A diversidade tem limites, e preferimos que você os ouça de nós.

Ela dá a um dispositivo NoWayOS falhas diferentes, não nenhuma. Ela não faz nada pelo que dois sistemas compartilham: a energia, a rede, os serviços por trás deles, ou um erro sobre o que a tarefa deveria ser. E algumas das partes de código aberto do NoWayOS também são usadas em outros softwares, e é por isso que cada imagem lista cada componente que contém, para que você possa ler o que ela tem em comum com o sistema ao lado.

O NoWayOS está em desenvolvimento, então este é um papel para o qual ele é projetado, não um papel que já tenha cumprido. A página de segurança diz em que ele se apoia.

Os engenheiros da Apollo não levaram um segundo sistema porque esperavam que o primeiro falhasse. Levaram porque não podiam provar que ele não falharia, e cuidaram para que aquilo que parasse o primeiro não encontrasse nada de familiar no segundo.

Atacamos o nosso próprio build a cada mudança

2026-11-13T00:00:00Z

Eis uma pergunta incômoda para qualquer teste de segurança: ele já falhou alguma vez? Um teste que nunca falhou pode estar passando porque o sistema é sólido, ou porque o teste não enxerga nada. De fora, as duas coisas são exatamente iguais.

Por isso o NoWayOS não se limita a testar a sua segurança. Ele a ataca, a cada mudança, e confere se os ataques são barrados.

Estender a mão para o que não é seu

Cada parte de um sistema NoWayOS roda em seu próprio compartimento sobre o seL4, com apenas o que lhe foi concedido. Os testes de isolamento enviam sondas através dessas fronteiras de propósito. Uma lê um endereço que nunca recebeu. Uma escreve em uma página que só pode ler. Uma, que tem exatamente o que a interface do usuário tem, tenta escrever na página de controle do vídeo, que a interface só pode ler. Outra, que tem exatamente o que o cliente de rede tem, tenta escrever na memória do driver de rede.

O seL4 precisa barrar todas elas, e uma parte que não tem nada a ver com isso precisa continuar rodando, intacta.

Um teste feito para falhar

Então vem a virada. Ao lado do teste de isolamento da interface do usuário fica uma variante com uma concessão ampliada de propósito: o substituto da interface recebe a página privada do vídeo. O teste dessa variante precisa falhar. Se algum dia ele passasse, o teste de isolamento estaria cego, e o build diria isso.

A mesma ideia percorre as demais verificações. Cada decodificador de mensagens entre partes tem provas limitadas, do verificador de modelos Kani, de que nunca entra em pânico, nunca estoura e nunca lê fora dos limites. Verificações por mutação então quebram os decodificadores deliberadamente, para mostrar que as provas percebem. Cada analisador de entradas externas passa por fuzzing com dados hostis.

Tudo isso faz parte do make ci, o controle pelo qual toda mudança precisa passar. Os testes de isolamento rodam sempre; uma prova ou uma rodada de fuzzing é repetida sempre que muda o código que ela cobre.

Controles fora de alcance

Um controle é tão forte quanto a mão que pode alterá-lo. Por isso as verificações pelas quais toda contribuição ao NoWayOS precisa passar estão definidas no Defence Agent, um repositório público próprio. Um pull request que toca em um controle é sinalizado para o mantenedor.

O Defence Agent testa a si mesmo do mesmo jeito: vinte pull requests armados, cada um escondendo algo que um revisor poderia deixar passar. Há texto oculto da direita para a esquerda em um comentário, uma letra trocada pela sua sósia cirílica, uma dependência buscada direto de um repositório git, um workflow que executaria código não confiável. Cada um precisa ser pego, enquanto três mudanças reais do passado precisam passar.

Evidências, não adjetivos

Nada disso torna um dispositivo “inhackeável”. Nada torna, e nunca diremos isso. O que você recebe são evidências: um registro do que foi tentado, do que foi barrado, e o comando que mostra isso. Leia as evidências de uma imagem real, ou os próprios controles.

O que uma prova pode prometer

2026-11-13T00:00:00Z

Em geral, confia-se em um software porque ele foi testado. Alguém pensou nas formas como ele poderia falhar, experimentou cada uma e viu como ele se saía. Isso funciona bem, até chegar o caso em que ninguém pensou.

Uma prova começa pela outra ponta. Ela não experimenta casos. Ela mostra, com matemática, que uma afirmação vale para todos.

Todos os casos, não só os que testamos

Tome uma promessa pequena: este código nunca lê além do fim do seu buffer. Um teste pode lhe dar mil entradas, ou um bilhão, e relatar que nenhuma o fez falhar. Uma prova diz algo de outra natureza: não há entrada que o faça falhar. Nenhuma foi encontrada, e nenhuma existe.

O preço é o rigor. Uma prova precisa de um enunciado exato do que o código deve fazer, a sua especificação, e de um argumento que ligue cada linha do código a ele. Em software de verdade, esse argumento é longo demais para uma pessoa conferir a olho. Então um computador confere.

Verificada por máquina

É isso que “verificada por máquina” quer dizer. A prova é escrita por inteiro, em uma linguagem que um programa chamado assistente de provas consegue ler, e o programa confere cada passo com as regras da lógica. Ele não se cansa na página novecentos, e não aceita a palavra de ninguém.

As provas do seL4 são verificadas assim, em um assistente de provas chamado Isabelle/HOL. Elas são públicas, e qualquer pessoa pode executá-las de novo.

O que dizem as provas do seL4

O seL4 é o kernel sobre o qual todo sistema NoWayOS roda: cerca de 10.000 linhas de código, e o único código com controle total do dispositivo. O tamanho é o ponto. Um argumento sobre dez mil linhas pode ser concluído. Um argumento sobre dezenas de milhões, ainda não.

A seL4 Foundation apresenta as provas em camadas:

O código faz o que a especificação diz, e nada mais. Disso decorre uma lista de coisas que o kernel não pode fazer: estourar um buffer, seguir um ponteiro nulo, vazar memória, dividir por zero.
O programa que roda corresponde ao código que foi provado. Há um compilador entre os dois, então outra prova confere a saída dele.
O kernel consegue manter separadas as partes de um sistema. Uma parte não pode alterar os dados de outra, nem lê-los, nem tomar os recursos de que ela precisa, a menos que tenha recebido esse direito.
Um sistema pode iniciar no estado para o qual foi projetado, com exatamente as concessões que a sua descrição lista.

Nem toda camada está concluída para todo processador e toda configuração. Isso importa, e voltaremos ao assunto.

O que uma prova toma como dado

Uma prova tem exatamente o alcance do seu enunciado, e se apoia nas suas premissas. O seL4 registra as dele por escrito: que o hardware se comporta como o seu modelo diz, que algumas centenas de linhas do código de mais baixo nível estão certas, que o código que roda antes de o kernel iniciar fez o seu trabalho. A prova de confidencialidade não cobre os tempos de execução.

Ela não diz nada sobre se a especificação pede a coisa certa, nem sobre o software acima do kernel. Um kernel provado vai isolar fielmente um programa que tem um defeito. O defeito continua lá. Ele só não consegue alcançar mais nada.

Isso não é uma fraqueza das provas. É o que faz delas algo que vale a pena ter: elas dizem com precisão o que cobrem, e assim você sabe com precisão o que sobra.

Onde o NoWayOS está

Esta é a posição, sem rodeios. O NoWayOS roda sobre o seL4, mas nenhuma imagem do NoWayOS está hoje dentro das provas concluídas do seL4. O NoWayOS usa a configuração de criticidade mista do seL4, cujas provas para os nossos processadores estão em andamento. E as provas do seL4 nunca cobriram o código do próprio NoWayOS. Por isso não chamamos o NoWayOS de “formalmente verificado”, e não vamos chamar.

Cada imagem diz onde está. Um arquivo ao lado dela lista a configuração do seu kernel, opção por opção, ao lado daquela que o seL4 provou. A página Segurança mostra um de verdade.

Provas menores, as nossas

O código do NoWayOS obtém a sua garantia por outro caminho: Rust, isolamento, revisão, testes e provas de um tipo mais modesto.

Cada decodificador das mensagens que passam entre as partes de um sistema tem provas limitadas, feitas com um verificador de modelos chamado Kani. Uma prova limitada cobre toda entrada até um tamanho declarado, aqui o registro mais longo que um decodificador aceita. Dentro desse limite, ela é uma prova de verdade: nenhuma entrada faz o decodificador entrar em pânico, estourar ou ler fora dos limites. Além do limite, ela não diz nada, e é por isso que o limite é a entrada mais longa que existe.

Depois quebramos os decodificadores de propósito, para ter certeza de que as provas percebem. Uma prova que não pode falhar não é melhor do que um teste que não pode.

O tamanho real disso

Uma prova não torna nada “inhackeável”. Ela torna uma afirmação verdadeira, em todos os casos, sob premissas que você pode ler. Conheça a afirmação e as premissas, e você sabe o que tem.

É por isso que o NoWayOS é construído sobre o kernel que tem essas provas, e por isso ele diz a você, imagem por imagem, até onde elas vão.

Por que um dispositivo NoWayOS não tem shell

2026-11-13T00:00:00Z

A maioria dos ataques a um dispositivo dedicado não mira a tarefa que ele executa. Mira o resto do computador em que ele roda: o shell deixado ali para manutenção, o serviço de acesso remoto que ninguém desligou, o navegador por trás da aplicação, a área de trabalho a uma falha de distância.

Esse “resto do computador” está em toda parte. O gateway que leva as leituras para fora de uma estação de tratamento de água, o terminal na sala de controle de uma rede elétrica, os dispositivos de que um hospital depende, o painel na lateral de uma máquina, a tela no saguão de uma estação: muitos rodam um sistema operacional de uso geral com uma tarefa por cima, e todo o resto continua lá embaixo, desligado por configurações. O modo quiosque é a versão mais simples. Cada invasão é alguém encontrando a configuração que passou despercebida.

Deixar de fora, em vez disso

O NoWayOS começa pela outra ponta. Uma imagem do NoWayOS contém a aplicação do dispositivo, os drivers que essa aplicação usa e o microkernel seL4. Essa é a lista inteira.

Não há shell em que cair, porque nenhum shell jamais foi incluído. Não há login remoto com senha para adivinhar. Não há área de trabalho para onde escapar. Não há motor de navegador à espera de uma página maliciosa. Não dá para configurar errado um software que não está lá.

Tudo isso diz respeito ao sistema operacional. A aplicação que roda por cima é outra história: ela pode fazer os seus usuários entrarem com login, e pode fazer login em outros sistemas, sempre que a sua tarefa pedir. O que ela não tem por baixo é um sistema operacional em que alguém possa fazer login.

Chamamos isso de Single Purpose OS: um computador sem mais nada para fazer.

E o que está lá fica isolado

Deixar coisas de fora é metade da história. Cada parte que permanece (a rede, a tela, a entrada, a aplicação) roda em um compartimento próprio, um domínio de proteção nos termos do seL4, e alcança apenas o que lhe foi concedido. O driver de rede move pacotes. O driver de vídeo desenha. A aplicação fala com cada um por mensagens de tamanho fixo.

Cada concessão está registrada em um arquivo, um fato por linha, e o build falha se o sistema e o arquivo divergirem. Tudo é construído para que uma falha em uma parte fique nessa parte.

“Mas como se conserta isso sem um shell?”

É a primeira pergunta dos engenheiros, e é justa. Ninguém faz login no sistema operacional de um dispositivo NoWayOS: ele não tem contas, então não há usuário com quem entrar. Você constrói uma nova imagem e substitui a antiga. Hoje isso significa construí-la e carregá-la na placa; atualizações assinadas, verificadas pelo dispositivo e capazes de voltar atrás com segurança, estão projetadas e a caminho.

Em troca, você tem um dispositivo que inicia direto na sua única tarefa, com muito menos para corrigir e muito menos para atacar. Para os sistemas de que um país depende, essa troca é exatamente o objetivo.

Veja você mesmo

As evidências de uma imagem real do NoWayOS, o seu arquivo de concessões, a sua lista de materiais e o seu registro de configuração do seL4, estão na nossa página de segurança. Sem cadastro, sem script. Só os arquivos.