Moins, à dessein
Single Purpose OS
Un ordinateur qui n’a rien d’autre à faire.
Pas de navigateur. Pas de bureau. Pas de shell. Pas d’identifiants. Une seule tâche, construite avec le seul code dont elle a besoin, cloisonnée en compartiments sur le micronoyau seL4 et écrite en Rust.
Fonctionne aujourd’hui dans QEMU et sur le Raspberry Pi 5 · Open source, sur GitHub
01 / Le principe de la tâche unique
Comment nous en sommes arrivés là
Tout est parti des lieux qui n’ont pas droit à l’erreur.
Nous ne cherchions pas à écrire un système d’exploitation. Nous cherchions à protéger quelques appareils très importants, et nous retombions sans cesse sur le même problème, caché dessous.
- La mission
- Protéger les systèmes sur lesquels repose un pays : les commandes qui font circuler le courant et gardent l’eau propre, les réseaux dont dépend un hôpital, les passerelles qui font sortir leurs données, les terminaux des salles de contrôle, et chaque appareil autour d’eux, jusqu’à l’écran devant lequel s’arrête un inconnu dans un lieu public. Chacun d’eux n’avait qu’une seule tâche. Chacun tournait sous un système d’exploitation fait pour en accomplir des milliers.
- Le hic
- Un système généraliste arrive avec tout ce dont il pourrait avoir besoin un jour : un navigateur, un bureau, un shell, des identifiants, des services en arrière-plan. Verrouillez-le sur une seule application, et tout cela reste là, en dessous, à attendre que quelqu’un trouve le chemin pour y revenir. Chaque ligne en trop est une chose de plus à corriger, et à attaquer.
- Le déclic
- Alors nous avons posé la question inverse : et si l’appareil ne contenait que sa seule tâche ? Nous sommes partis de seL4, avons écrit en Rust tout ce qui nous revenait au-dessus, enfermé chaque partie dans un compartiment qui lui est propre et laissé tout le reste de côté. Puis nous avons consigné les éléments de preuve, pour que personne n’ait à nous croire sur parole.
- La surprise
- Puis nous avons regardé autour de nous. La passerelle du poste électrique, le terminal de la salle de contrôle, le panneau sur le flanc d’une pompe, le boîtier entre deux réseaux, l’afficheur sur le mur d’une gare : presque chaque appareil dédié n’a qu’une seule tâche. Ce qui avait commencé comme une armure pour les infrastructures critiques s’est révélé une meilleure façon de les construire tous. Nous l’appelons un Single Purpose OS.
Moins à attaquer. Bien moins à corriger. Rien d’autre à faire.
Ce que nous entendons par là
La vocation est intégrée. Tout le reste est laissé de côté.
Un Single Purpose OS est construit pour l’unique tâche d’un appareil, au lieu d’être construit pour tout faire tourner puis verrouillé sur une seule chose. Trois traits le définissent.
Bâti pour une seule tâche
L’image de l’appareil contient son application, les pilotes que cette application utilise et le noyau. Rien de ce dont une autre tâche pourrait avoir besoin n’y figure : ni navigateur, ni bureau, ni shell, ni gestionnaire de paquets, ni compte utilisateur.
Cloisonné de l’intérieur
Chaque partie (l’écran, les entrées, le réseau, l’application) s’exécute dans un compartiment qui lui est propre et n’atteint que ce qui lui a été accordé. Tout est conçu pour qu’une défaillance dans une partie y reste confinée.
Preuves à l’appui
Il est livré avec les éléments de preuve de ce qu’il contient et de ce que chaque partie a le droit de faire : chaque droit consigné, chaque composant répertorié, et des vérifications que chacun peut exécuter.
Ce n’est pas un mode kiosque, qui verrouille un système généraliste sur une seule application et laisse tout le reste en place. Ni un OS mono-utilisateur, qui limite qui utilise un ordinateur, pas ce qu’il contient.
Ce qui n’y est pas
Moins de logiciel. Délibérément.
La plupart des appareils dédiés font tourner un système généraliste avec une application par-dessus, et tout le reste toujours en dessous. NoWayOS part de la tâche, n’ajoute que ce dont elle a besoin et laisse le reste de côté. Voici la différence.
| Un appareil verrouillé classique | Un appareil NoWayOS | |
|---|---|---|
| Navigateur web et moteur JavaScript | Inclus | Non intégré |
| Bureau et système de fenêtrage | Inclus | Non intégré |
| Shell et ligne de commande | Inclus | Non intégré |
| Gestionnaire de paquets | Inclus | Non intégré |
| Comptes utilisateurs et identifiants | Inclus | Non intégré |
| Services en arrière-plan | Inclus | Non intégré |
| Réglages pour tout verrouiller | Inclus | Non intégré |
| Noyau | Généraliste : des dizaines de millions de lignes | seL4 : environ 10 000 lignes |
| Pilotes | Pour le matériel qu’il pourrait rencontrer | Uniquement pour le matériel qu’il utilise |
| Votre application | Inclus | Inclus |
Screen Compiler
Vous aimez React. Nous aussi.
Vous voulez des interfaces riches et modernes, construites avec le flux de travail que vous connaissez déjà ? Écrivez vos écrans en React. Le Screen Compiler les transforme en composants Rust natifs qui s’exécutent directement sur NoWayOS : pas de navigateur, pas de JavaScript, pas de page web à attaquer.
- Gardez vos outils : composants, props, design tokens et l’éditeur que vous utilisez déjà.
- De vraies briques : mises en page, textes, boutons, champs de saisie, cases à cocher, groupes de boutons radio, cartes, encadrés, barres de progression et icônes.
- Exact ou rien. Il convertit son sous-ensemble à l’identique et refuse tout le reste, en indiquant le fichier, la ligne et la colonne. Il ne devine jamais.
- Vérifié au pixel près. Chaque écran converti est dessiné par NoWayOS et comparé à son image approuvée.
<Column gap={SPACE_SM} padding={SPACE_LG}>
<Text id="title">Welcome</Text>
<Text>Touch Start to begin.</Text>
<Button id="start" onPress={onStart}>
Start
</Button>
</Column>let n1 = b.text("Welcome")?; // welcome.tsx:17:9
let n2 = b.text("Touch Start to begin.")?;
let n5 = b.button("Start", actions::START)?;
let n0 = b.column(
ui::Layout::new()
.gap(super::tokens::SPACE_SM)
.padding(super::tokens::SPACE_LG),
&[n1, n2, n5],
)?;Extrait abrégé de l’un des écrans de test du Screen Compiler et du Rust qu’il génère.
Pourquoi c’est important
Une seule tâche. Et c’est bien assez.
Construisez un ordinateur pour une seule chose, et vous pouvez le construire tout autrement. Voici ce que cela vous apporte.
Plus sûr
Aucun moyen d’exploiter ce qui n’a jamais été intégré.
- Pas de moteur de navigateur, pas de système de fenêtrage, pas de shell, pas de gestionnaire de paquets, pas de comptes utilisateurs. Ce qui n’est pas dans l’image ne peut pas être retourné contre elle.
- L’écran, les entrées, le réseau et votre application vivent chacun dans un compartiment étanche qui leur est propre, et n’atteignent que ce qui leur a été accordé. Tout est construit pour qu’une défaillance dans une partie reste dans cette partie.
- En son cœur, seL4, que la seL4 Foundation qualifie de « noyau de système d’exploitation au plus haut niveau d’assurance et le plus rapide du monde ».
- Du Rust de bout en bout. Le code unsafe ne vit que dans une poignée de crates relues, et la compilation fait respecter la liste.
Plus efficace
Rien d’inactif. Rien qui gêne.
- Pas de services en arrière-plan, ni de programme de mise à jour pour des logiciels dont vous ne vous servez jamais. À la mise sous tension, il se consacre aussitôt à son unique tâche.
- Chaque octet est décidé à la compilation : chaque partie reçoit une quantité fixe de mémoire et ne peut jamais en prendre davantage. La plupart du code de l’appareil n’alloue rien du tout, et même le client TLS reçoit un budget fixe : s’il vient à l’épuiser, il s’arrête proprement au lieu de grossir.
- Une interface native et nette qui ne redessine que ce qui a changé, à l’aise sur du matériel bon marché comme le Raspberry Pi 5.
Plus simple à prendre en main
Un langage. Un conteneur. L’émulateur d’abord.
- Du Rust, des pilotes jusqu’à l’interface utilisateur.
- Concevez vos écrans en React. Le Screen Compiler les transforme en Rust natif à la compilation : une interface moderne, sans moteur de navigateur ni JavaScript sur l’appareil. Ou écrivez-les en Rust.
- Les chaînes d’outils, le SDK seL4 Microkit et QEMU sont fournis, en versions figées, dans un seul conteneur de développement. Votre machine n’a besoin que de Podman et de make, plus Python pour piloter un Raspberry Pi.
Plus facile à prouver
Chaque droit consigné. Chaque image inventoriée.
- Chaque capacité qu’un système accorde est listée dans un fichier, et la compilation échoue si les deux divergent.
- Chaque image est livrée avec une nomenclature logicielle et un relevé de sa configuration seL4.
- Des preuves bornées que chaque décodeur de messages ne panique jamais, ne déborde jamais et ne lit jamais hors limites, plus du fuzzing et des vérifications de licences et d’avis de sécurité : chacune est une commande que vous pouvez exécuter vous-même.
Quand tout en dépend, ne lui confiez qu’une seule tâche.
Certains appareils ont un travail trop important pour le partager avec des distractions : les commandes d’un réseau électrique, la passerelle de sortie d’une station de traitement des eaux, le terminal d’une salle de contrôle, la frontière entre deux réseaux. NoWayOS est conçu autour du rôle que chaque appareil doit remplir, avec les éléments de preuve qui vous aident à comprendre ce qu’il contient.
Des preuves, pas des adjectifs
Il ne se mêle que de ses affaires. Vérifiez par vous-même.
Une affirmation de sécurité ne vaut que par les éléments de preuve qui l’étayent. NoWayOS les consigne, et chacun d’eux provient d’une commande que vous pouvez exécuter.
Chaque droit consigné
Le fichier des droits de chaque système liste chaque priorité, région mémoire, périphérique, interruption et canal qu’il accorde. La compilation échoue si le système et la liste divergent.
Une isolation testée par l’échec
Les tests d’isolation tentent d’atteindre ce qui ne leur a pas été accordé, et seL4 doit les arrêter. Une variante dont un droit a été volontairement élargi doit échouer, ce qui montre que le test en est capable.
Chaque image inventoriée
Une nomenclature logicielle CycloneDX pour chaque image : le noyau, le chargeur, chaque domaine de protection et les crates qu’il contient, chacun avec son empreinte.
Des points de contrôle hors de portée
Les vérifications que chaque contribution doit passer vivent dans Defence Agent, un dépôt public à part entière, et une pull request qui touche à un point de contrôle est signalée au mainteneur.
Au grand jour
Quatre projets. Une tâche chacun.
Les quatre sont open source, développés ouvertement au sein de l’organisation NoWayOS sur GitHub. Clonez-les, compilez-les et vérifiez chaque ligne par vous-même.
NoWayOS
Le Single Purpose OS.
Des modèles de domaines de protection sur seL4 et Microkit, des messages typés, des pilotes, le réseau et une interface utilisateur native, avec le conteneur de développement et les vérifications avec lesquels se construit chaque dépôt NoWayOS.
- Statut
- En développement
- Licence
- MIT OR Apache-2.0
Screen Compiler
Concevez en React. Livrez du Rust natif. Aucun navigateur sur l’appareil.
Convertit des écrans React, écrits en TSX dans un sous-ensemble déclaré, en Rust pour l’interface utilisateur de NoWayOS. Il s’exécute à la compilation, sur votre machine ou en CI, et n’est jamais embarqué.
- Statut
- En développement : le sous-ensemble v0 et les premiers éléments de la v1
- Licence
- MIT
Showcase
Des applications sécurisées à faire tourner sur un Raspberry Pi.
Un kit pour des écrans en libre-service sécurisés, une application de référence sur laquelle bâtir, et un lanceur d’exemples sous des marques fictives, sur lequel démarre le Raspberry Pi 5.
- Statut
- À un stade précoce, et non déployable
- Licence
- MIT OR Apache-2.0
Defence Agent
Les points de contrôle que chaque contribution doit franchir, hors de portée de la pull request.
Chaque point de contrôle de sécurité qu’une modification des projets ouverts de NoWayOS doit franchir, consigné avec la menace à laquelle il répond et qui a le droit de le modifier, ainsi que l’agent qui les exécute. Une pull request ne modifie ni ne fournit jamais ce qui la juge.
- Statut
- Public : les points de contrôle sont consignés ; l’agent et ses outils suivront
- Licence
- MIT OR Apache-2.0
Partenaires commerciaux
Des produits commerciaux, construits sur NoWayOS.
Adappt.ai, qui parraine NoWayOS, en est le premier partenaire commercial. Adappt.ai construit deux produits commerciaux sur NoWayOS, tous deux en développement.
Vous souhaitez devenir partenaire commercial ? Écrire à partners@nowayos.com
- Remote Desktop
- Une vue durcie. Un poste sécurisé pour un bureau Windows distant, conçu pour enfermer la connexion dans un compartiment qui lui est propre et tenir les identifiants hors de sa portée.
- Data Diode
- Aucun chemin de retour. Une frontière à sens unique pour faire sortir des données d’un réseau protégé, conçue autour d’une liaison qui ne transporte la lumière que dans un seul sens.
Où en est-on
Il tourne déjà. Il n’est pas encore fini.
NoWayOS est en développement et pas encore utilisable en production, et ses API vont changer. Voici ce qui fonctionne aujourd’hui, et ce qui vient ensuite.
- Dans QEMU
- Plus de cinquante systèmes démarrent et vérifient leur propre sortie, d’un premier domaine de protection à la pile réseau qui obtient un bail DHCP, en passant par l’état de repli sûr du superviseur et une interface utilisateur cliquable.
- Sur le Raspberry Pi 5
- L’interface utilisateur sur un écran HDMI, un clavier et une souris USB, les timers, le watchdog et la réinitialisation par le superviseur fonctionnent tous sur la carte. D’autres éléments de son matériel sont en cours de mise en service.
- À venir
- Le démarrage sécurisé, les mises à jour signées appliquées sur l’appareil, et le matériel industriel (NXP i.MX8).
- Les preuves de seL4
- Chaque système tourne sur seL4, mais aucune image NoWayOS n’utilise encore une configuration couverte par les preuves achevées de seL4. Chaque image consigne celle qu’elle utilise.
Suivre le travail
Une seule vocation. Beaucoup à explorer.
Commencez par la conception, examinez les éléments de preuve, ou construisez votre premier système avec les guides du développeur. Au passage, ce site suit la même règle : pas de scripts, pas de cookies, rien d’autre à faire.