Le Journal de NoWayOS

React en entrée, Rust en sortie

2026-11-13T00:00:00Z

Les interfaces modernes sont conçues en React. Si bien qu’un très grand nombre d’appareils dédiés, du pupitre de commande au distributeur de billets, embarquent un moteur de navigateur entier, l’un des programmes les plus volumineux et les plus attaqués qui soient, pour dessiner quelques boutons et les mots « Touch Start to begin ».

Nous voulions la méthode de design moderne sans le navigateur. Nous avons donc construit le Screen Compiler.

Écrivez l’écran en React

Vos designers et vos développeurs front-end gardent leurs outils : composants, props, design tokens, leur éditeur. Ils écrivent l’écran en TSX (celui-ci est abrégé à partir de l’un des écrans de test du 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>

Livrez du Rust tout simple

À la compilation, sur votre machine ou en CI, le Screen Compiler en fait du Rust pour le runtime d’interface de 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>

Chaque ligne renvoie au TSX dont elle vient. L’appareil reçoit ce code et rien d’autre : pas de moteur JavaScript, pas de navigateur, pas de page web à attaquer. Le Screen Compiler lui-même n’est jamais embarqué.

Exact, ou rien

Un convertisseur qui devine est un convertisseur auquel on ne peut pas se fier. Le Screen Compiler convertit exactement son sous-ensemble déclaré de TSX, et refuse tout le reste en donnant le fichier, la ligne et la colonne. Il n’approxime jamais. Le Rust qu’il écrit ne contient ni unsafe, ni unwrap, ni panic.

Ensuite, chaque écran converti est dessiné par le moteur de rendu de NoWayOS et comparé, pixel par pixel, à son image approuvée. Si un seul pixel bouge, la compilation le dit.

Où il en est

Le Screen Compiler est en développement : son premier sous-ensemble est construit et le suivant est en cours. Il est open source sous licence MIT, sur GitHub à côté de NoWayOS. Si votre équipe conçoit en React et construit des appareils qui comptent, nous serions heureux de vous lire.

Le secours qui n’était pas une copie

2026-11-13T00:00:00Z

Tout le monde sait qu’il faut un système de secours. Moins nombreux sont ceux qui posent la question gênante qui suit : un secours de quoi, au juste ?

Cinq alarmes

Le 20 juillet 1969, le module lunaire d’Apollo 11 était à quelques minutes de la surface de la Lune quand son ordinateur de guidage a déclenché une alarme sur laquelle l’équipage a dû interroger le centre de contrôle. Puis une autre. Cinq en tout, dans la dernière partie de la descente.

L’ordinateur était surchargé. Ce qu’il a fait ensuite compte parmi les grandes réussites d’ingénierie de cette histoire : à chaque fois, il a redémarré, abandonné le travail qui pouvait attendre et repris aussitôt celui qui ne le pouvait pas. L’alunissage s’est poursuivi.

C’est la partie que tout le monde raconte. Celle qui mérite d’être racontée ensuite s’est produite le lendemain.

Le second système

Le module lunaire emportait un second système de guidage, et ce n’était pas une copie de rechange du premier. Une autre entreprise l’avait construit, sur un autre principe. Le système principal gardait ses repères grâce à une plateforme qui pivotait librement sur des cardans. Le second n’avait pas de cardans du tout : ses capteurs étaient fixés directement au vaisseau, et il déterminait où était le haut par le calcul.

Il était là pour ramener l’équipage en orbite si le système principal venait à s’arrêter. Pendant l’alunissage, on n’a pas fait appel à lui.

Puis, lors de la remontée pour s’amarrer au module de commande, une série de manœuvres a amené la plateforme du système principal dans la seule position qu’une plateforme à cardans ne supporte pas, et il a perdu sa référence d’attitude. L’équipage est passé sur le second système pour stabiliser le vaisseau, et s’est amarré.

Le second système n’aurait pas pu tomber en panne de la même façon. Il n’avait pas la pièce.

Deux fois le même

Voici maintenant l’autre histoire. En 1996, la première Ariane 5 a décollé avec deux centrales de référence inertielle pour lui dire dans quelle direction elle pointait : l’une active, l’autre en réserve. Elles étaient identiques, jusqu’au logiciel.

Trente-sept secondes après le décollage, un nombre, dans ce logiciel, est devenu trop grand pour la place qui lui était réservée. La centrale en réserve s’est arrêtée. La centrale active, qui exécutait le même code sur le même vol, s’est arrêtée elle aussi. Le rapport de la commission d’enquête est public, et il est sans détour : il n’y avait rien vers quoi basculer, parce que le secours avait déjà suivi le même chemin.

Deux copies. Une faute. Plus rien.

Comment les ingénieurs l’appellent

Une faute qui emporte ensemble un système et son secours est une défaillance de cause commune. La parade est la redondance diversifiée : un second système construit assez différemment pour que ce qui arrête le premier ne se trouve pas dans le second.

La navette spatiale volait ainsi. Quatre de ses ordinateurs de vol exécutaient le logiciel d’une entreprise ; le cinquième exécutait un logiciel écrit séparément par une autre. Quatre copies vous protègent d’un ordinateur qui tombe en panne. Elles ne vous protègent pas d’un programme qui est faux, parce que les quatre l’exécutent.

Cela a un coût. Le premier lancement de la navette a été annulé parce que le cinquième ordinateur et les quatre autres n’arrivaient pas à s’accorder sur l’heure. Deux conceptions demandent plus de travail qu’une, et il faut les faire se rejoindre.

Où NoWayOS entre en scène

La plupart des appareils dédiés tournent aujourd’hui sur l’un d’un très petit nombre de systèmes d’exploitation généralistes. Leurs secours aussi. Quand un défaut apparaît dans un moteur de navigateur, un bureau ou un noyau de dizaines de millions de lignes, ou quand une mauvaise mise à jour est diffusée, il apparaît partout où ce logiciel tourne, le même jour.

Un appareil NoWayOS est différent en profondeur. Son noyau est seL4, environ 10 000 lignes. Tout ce que nous avons écrit au-dessus est en Rust. Il n’a ni moteur de navigateur, ni bureau, ni shell ; un défaut dans l’un d’eux ne s’y trouve donc pas.

NoWayOS n’a donc pas besoin de remplacer ce que vous exploitez pour être utile. Il peut se tenir à côté : une seconde façon d’accomplir une tâche essentielle, bâtie sur un autre principe.

Ce qu’il ne fait pas

La diversité a des limites, et nous préférons que vous les appreniez de nous.

Elle donne à un appareil NoWayOS des fautes différentes, pas une absence de fautes. Elle ne fait rien pour ce que deux systèmes partagent : l’alimentation, le réseau, les services derrière eux, ou une erreur sur ce que la tâche devait être. Et certaines des briques open source de NoWayOS sont aussi utilisées dans d’autres logiciels ; c’est pourquoi chaque image énumère chaque composant qu’elle contient, pour que vous puissiez lire ce qu’elle a en commun avec le système d’à côté.

NoWayOS est en développement : c’est donc un rôle pour lequel il est conçu, pas un rôle qu’il a déjà tenu. La page Sécurité dit sur quoi il repose.

Les ingénieurs d’Apollo n’ont pas emporté un second système parce qu’ils s’attendaient à ce que le premier tombe en panne. Ils l’ont emporté parce qu’ils ne pouvaient pas prouver qu’il ne tomberait pas en panne, et ils ont veillé à ce que ce qui arrêterait le premier ne trouve rien de familier dans le second.

Nous attaquons notre propre build à chaque modification

2026-11-13T00:00:00Z

Voici une question gênante pour tout test de sécurité : a-t-il déjà échoué ? Un test qui n’a jamais échoué réussit peut-être parce que le système est sain, ou parce que le test ne voit rien du tout. De l’extérieur, les deux se ressemblent trait pour trait.

NoWayOS ne se contente donc pas de tester sa sécurité. Il l’attaque, à chaque modification, et vérifie que les attaques sont arrêtées.

Tendre la main vers ce qui n’est pas à soi

Chaque partie d’un système NoWayOS tourne dans son propre compartiment sur seL4, et ne détient que ce qui lui a été accordé. Les tests d’isolation envoient exprès des sondes à travers ces frontières. L’une lit une adresse qu’on ne lui a jamais donnée. Une autre écrit sur une page qu’elle ne peut que lire. Une autre, qui détient exactement ce que détient l’interface utilisateur, tente d’écrire sur la page de contrôle de l’écran, que l’interface ne peut que lire. Une autre encore, qui détient exactement ce que détient le client réseau, tente d’écrire dans la mémoire du pilote réseau.

seL4 doit les arrêter toutes, et une partie témoin doit continuer de tourner, intacte.

Un test fait pour échouer

Vient ensuite le retournement. À côté du test d’isolation de l’interface utilisateur se trouve une variante dont un droit a été élargi exprès : la doublure de l’interface reçoit la page privée de l’écran. Le test de cette variante doit échouer. S’il réussissait un jour, le test d’isolation serait aveugle, et la compilation le dirait.

La même idée traverse le reste des contrôles. Chaque décodeur des messages entre parties a des preuves bornées, issues du vérificateur de modèles Kani, établissant qu’il ne panique jamais, ne déborde jamais et ne lit jamais hors limites. Des contrôles par mutation cassent ensuite les décodeurs exprès, pour montrer que les preuves le remarquent. Chaque analyseur d’entrées venues de l’extérieur est soumis au fuzzing avec des données hostiles.

Tout cela fait partie de make ci, le contrôle que chaque modification doit franchir. Les tests d’isolation tournent à chaque fois ; une preuve ou une campagne de fuzzing est rejouée dès que le code qu’elle couvre change.

Des contrôles hors de portée

Un contrôle ne vaut que par la main qui peut le modifier. Les contrôles que chaque contribution à NoWayOS doit franchir sont donc définis dans Defence Agent, un dépôt public à part. Une pull request qui touche à un contrôle est signalée au mainteneur.

Defence Agent se teste lui-même de la même façon : vingt pull requests piégées, chacune cachant quelque chose qu’un relecteur pourrait manquer. Il y a du texte caché écrit de droite à gauche dans un commentaire, une lettre remplacée par son sosie cyrillique, une dépendance récupérée directement depuis un dépôt git, un workflow qui exécuterait du code non fiable. Chacune doit être arrêtée, tandis que trois vraies modifications passées doivent passer.

Des preuves, pas des adjectifs

Rien de tout cela ne rend un appareil “impiratable”. Rien ne le fait, et nous ne le dirons jamais. Ce que vous obtenez, ce sont des éléments de preuve : la trace de ce qui a été tenté, de ce qui a été arrêté, et la commande qui le montre. Lisez les éléments de preuve d’une image réelle, ou les contrôles eux-mêmes.

Ce qu’une preuve peut promettre

2026-11-13T00:00:00Z

On fait le plus souvent confiance à un logiciel parce qu’il a été testé. Quelqu’un a imaginé ce qui pouvait mal tourner, l’a essayé, et a regardé le logiciel s’en sortir. Cela marche bien, jusqu’au cas auquel personne n’avait pensé.

Une preuve part de l’autre bout. Elle n’essaie pas des cas. Elle montre, par les mathématiques, qu’un énoncé vaut pour tous.

Tous les cas, pas seulement ceux qu’on a essayés

Prenons une petite promesse : ce code ne lit jamais au-delà de la fin de son tampon. Un test peut lui soumettre mille entrées, ou un milliard, et rapporter qu’aucune ne l’a mis en défaut. Une preuve dit autre chose, d’une autre nature : il n’existe aucune entrée qui le mette en défaut. On n’en a trouvé aucune, et il n’y en a aucune.

Le prix à payer est la rigueur. Une preuve exige un énoncé exact de ce que le code doit faire, sa spécification, et un raisonnement qui relie chaque ligne du code à cet énoncé. Pour un vrai logiciel, ce raisonnement est bien trop long pour qu’une personne le vérifie à l’œil. C’est donc un ordinateur qui le vérifie.

Vérifiée par machine

Voilà ce que signifie « vérifiée par machine ». La preuve est écrite en entier, dans un langage que sait lire un programme appelé assistant de preuve, et ce programme confronte chaque étape aux règles de la logique. Il ne fatigue pas à la page neuf cents, et il ne croit personne sur parole.

Les preuves de seL4 sont vérifiées ainsi, dans un assistant de preuve nommé Isabelle/HOL. Elles sont publiques, et chacun peut les rejouer.

Ce que disent les preuves de seL4

seL4 est le noyau sur lequel tourne chaque système NoWayOS : environ 10 000 lignes de code, et le seul code qui ait le contrôle total de l’appareil. Sa taille est l’essentiel. Un raisonnement sur dix mille lignes peut être mené à son terme. Un raisonnement sur des dizaines de millions ne le peut pas encore.

La seL4 Foundation présente ces preuves par couches :

Le code fait ce que dit la spécification, et rien de plus. Il en découle une liste de choses que le noyau ne peut pas faire : déborder d’un tampon, suivre un pointeur nul, laisser fuir de la mémoire, diviser par zéro.
Le programme qui s’exécute correspond au code qui a été prouvé. Un compilateur se tient entre les deux ; une preuve supplémentaire en vérifie donc la sortie.
Le noyau peut tenir séparées les parties d’un système. Une partie ne peut ni modifier les données d’une autre, ni les lire, ni lui prendre les ressources dont elle a besoin, à moins d’en avoir reçu le droit.
Un système peut démarrer dans l’état pour lequel il a été conçu, avec exactement les droits que sa description énumère.

Toutes les couches ne sont pas achevées pour tous les processeurs et toutes les configurations. Cela compte, et nous y reviendrons.

Ce qu’une preuve tient pour acquis

Une preuve a exactement la portée de son énoncé, et elle repose sur ses hypothèses. seL4 écrit les siennes : que le matériel se comporte comme le dit son modèle, que quelques centaines de lignes du code le plus proche du matériel sont justes, que le code exécuté avant le démarrage du noyau a fait son travail. La preuve de confidentialité ne couvre pas les temps d’exécution.

Elle ne dit rien sur la question de savoir si la spécification demande la bonne chose, et rien sur le logiciel au-dessus du noyau. Un noyau prouvé isolera fidèlement un programme qui contient un bogue. Le bogue est toujours là. Il ne peut simplement atteindre rien d’autre.

Ce n’est pas une faiblesse des preuves. C’est ce qui fait leur valeur : elles disent précisément ce qu’elles couvrent, et vous savez donc précisément ce qui reste.

Où se situe NoWayOS

Voici la position, sans détour. NoWayOS tourne sur seL4, mais aucune image NoWayOS n’entre aujourd’hui dans les preuves achevées de seL4. NoWayOS utilise la configuration à criticité mixte de seL4, dont les preuves pour nos processeurs sont en cours. Et les preuves de seL4 n’ont jamais couvert le code propre à NoWayOS. Nous ne disons donc pas que NoWayOS est “formellement vérifié”, et nous ne le dirons pas.

Chaque image dit où elle en est. Un fichier, à côté d’elle, énumère la configuration de son noyau, option par option, en regard de celle que seL4 a prouvée. La page Sécurité en montre un vrai.

De plus petites preuves, les nôtres

Le code de NoWayOS tire son assurance d’ailleurs : Rust, l’isolation, la relecture, les tests, et des preuves d’un genre plus modeste.

Chaque décodeur des messages qui circulent entre les parties d’un système a des preuves bornées, produites avec un vérificateur de modèles nommé Kani. Une preuve bornée couvre toute entrée jusqu’à une taille déclarée, ici l’enregistrement le plus long qu’un décodeur accepte. À l’intérieur de cette borne, c’est une vraie preuve : aucune entrée ne fait paniquer le décodeur, ne le fait déborder ni lire hors limites. Au-delà de la borne, elle ne dit rien, et c’est pourquoi la borne est l’entrée la plus longue qui soit.

Ensuite, nous cassons les décodeurs exprès, pour nous assurer que les preuves le remarquent. Une preuve qui ne peut pas échouer ne vaut pas mieux qu’un test qui ne le peut pas.

La juste mesure

Une preuve ne rend rien “impiratable”. Elle rend un énoncé vrai, dans tous les cas, sous des hypothèses que vous pouvez lire. Connaissez l’énoncé et les hypothèses, et vous savez ce que vous avez.

C’est pourquoi NoWayOS est bâti sur le noyau qui a ces preuves, et pourquoi il vous dit, image par image, jusqu’où elles vont.

Pourquoi un appareil NoWayOS n’a pas de shell

2026-11-13T00:00:00Z

La plupart des attaques contre un appareil dédié ne visent pas la tâche qu’il accomplit. Elles visent le reste de l’ordinateur sur lequel il tourne : le shell laissé là pour la maintenance, le service d’accès à distance que personne n’a coupé, le navigateur derrière l’application, le bureau à un plantage de distance.

Ce « reste de l’ordinateur » est partout. La passerelle qui sort les relevés d’une usine d’eau, le terminal dans la salle de contrôle d’un réseau électrique, les appareils sur lesquels compte un hôpital, le panneau sur le flanc d’une machine, l’écran dans le hall d’une gare : beaucoup tournent sur un système d’exploitation généraliste, avec une tâche par-dessus, et tout le reste encore là en dessous, désactivé par des réglages. Le mode kiosque en est la version la plus simple. Chaque compromission, c’est quelqu’un qui trouve le réglage qu’on a oublié.

Le laisser de côté, plutôt

NoWayOS part de l’autre bout. Une image NoWayOS contient l’application de l’appareil, les pilotes que cette application utilise, et le micronoyau seL4. C’est toute la liste.

Il n’y a pas de shell où atterrir, parce qu’aucun shell n’y a jamais été mis. Pas de connexion à distance dont on devinerait le mot de passe. Pas de bureau vers lequel s’échapper. Pas de moteur de navigateur qui attend une page malveillante. On ne peut pas mal configurer le réglage d’un logiciel qui n’est pas là.

Tout cela concerne le système d’exploitation. L’application qui tourne au-dessus, c’est autre chose : elle peut authentifier ses utilisateurs, et se connecter à d’autres systèmes, chaque fois que sa tâche le demande. Simplement, elle ne repose pas sur un système d’exploitation auquel quelqu’un peut se connecter.

Nous appelons cela un Single Purpose OS : un ordinateur qui n’a rien d’autre à faire.

Et ce qui reste est cloisonné

Laisser de côté, c’est la moitié du travail. Chaque partie qui reste (le réseau, l’écran, la saisie, l’application) tourne dans son propre compartiment, un domaine de protection dans les termes de seL4, et n’atteint que ce qui lui a été accordé. Le pilote réseau déplace des paquets. Le pilote d’affichage dessine. L’application parle à chacun par des messages de taille fixe.

Chaque droit est consigné dans un fichier, un fait par ligne, et la compilation échoue si le système et le fichier ne concordent pas. L’ensemble est construit pour qu’une faute dans une partie reste dans cette partie.

« Mais comment le réparer sans shell ? »

C’est la première question des ingénieurs, et elle est légitime. On ne se connecte pas au système d’exploitation d’un appareil NoWayOS : il n’a pas de comptes, il n’y a donc personne sous le nom de qui se connecter. On construit une nouvelle image et on remplace l’ancienne. Aujourd’hui, cela veut dire la construire et la charger sur la carte ; les mises à jour signées, vérifiées par l’appareil et capables de revenir en arrière en sécurité, sont conçues et en chemin.

En échange, vous obtenez un appareil qui démarre droit dans son unique tâche, avec bien moins à corriger et bien moins à attaquer. Pour les systèmes sur lesquels repose un pays, cet échange est tout l’intérêt.

Voyez par vous-même

Les éléments de preuve d’une image NoWayOS réelle, son fichier des droits, sa nomenclature et son relevé de configuration seL4, sont sur notre page Sécurité. Pas d’inscription, pas de script. Juste les fichiers.