13 de novembro de 2026
Atacamos o nosso próprio build a cada mudança
Um teste de segurança que não pode falhar não prova nada. Por isso os testes do NoWayOS vêm com versões feitas para falhar, e os seus controles ficam onde um pull request não alcança.
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.
Um teste feito para falhar
O testeA sonda tenta alcançar uma página que nunca lhe foi concedida. O seL4 a barra, e o teste passa.
A varianteUma concessão é ampliada de propósito. A sonda passa, então este teste precisa falhar. Se algum dia passasse, o primeiro teste estaria cego.
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.