Bewusst weniger
Single Purpose OS
Ein Computer, der sonst nichts zu tun hat.
Kein Browser. Kein Desktop. Keine Shell. Keine Logins. Nur eine Aufgabe, gebaut aus genau dem Code, den sie braucht, abgeschottet in Kammern auf dem seL4-Mikrokernel und geschrieben in Rust.
Läuft heute in QEMU und auf dem Raspberry Pi 5 · Open Source auf GitHub
01 / Das Prinzip der einen Aufgabe
Wie es dazu kam
Es begann an Orten, die sich keinen schlechten Tag leisten können.
Wir wollten nie ein Betriebssystem schreiben. Wir wollten ein paar sehr wichtige Geräte schützen und stießen darunter immer wieder auf dasselbe Problem.
- Der Auftrag
- Die Systeme schützen, auf die ein Land angewiesen ist: die Steuerungen, die den Strom fließen und das Wasser sauber halten, die Netze, auf die sich ein Krankenhaus verlässt, die Gateways, über die deren Daten nach außen gehen, die Terminals in der Leitwarte und jedes Gerät drumherum, bis hin zum Bildschirm, an den ein Fremder an einem öffentlichen Ort herantritt. Jedes davon hatte eine Aufgabe. Jedes lief auf einem Betriebssystem, das für Tausende gebaut war.
- Der Haken
- Ein Allzwecksystem bringt alles mit, was es je brauchen könnte: einen Browser, einen Desktop, eine Shell, Logins, Hintergrunddienste. Riegeln Sie es auf eine einzige App ab, und all das ist darunter immer noch da und wartet darauf, dass jemand einen Weg zurück findet. Jede zusätzliche Zeile ist etwas, das gepatcht werden muss, und etwas, das sich angreifen lässt.
- Die Wende
- Also stellten wir die umgekehrte Frage: Was, wenn das Gerät nur seine eine Aufgabe enthielte? Wir begannen mit seL4, schrieben alles Eigene darüber in Rust, schotteten jeden Teil in einer eigenen Kammer ab und ließen alles andere weg. Dann schrieben wir die Nachweise auf, damit uns niemand einfach glauben muss.
- Die Überraschung
- Dann sahen wir uns um. Das Gateway im Umspannwerk, das Terminal in der Leitwarte, das Bedienfeld an der Pumpe, die Box zwischen zwei Netzen, die Anzeige an der Bahnhofswand: Fast jedes dedizierte Gerät hat eine einzige Aufgabe. Was als Panzerung für kritische Infrastruktur begann, erwies sich als bessere Art, sie alle zu bauen. Wir nennen es ein Single Purpose OS.
Weniger anzugreifen. Viel weniger zu patchen. Sonst nichts zu tun.
Was wir meinen
Der Zweck ist eingebaut. Alles andere bleibt draußen.
Ein Single Purpose OS wird für die eine Aufgabe eines Geräts gebaut, statt für alles gebaut und dann auf eine Sache abgeriegelt zu werden. Drei Dinge machen es aus.
Für eine Aufgabe gebaut
Das Geräte-Image enthält die Anwendung, die Treiber, die diese Anwendung nutzt, und den Kernel. Nichts, was eine andere Aufgabe bräuchte, ist vorhanden: kein Browser, kein Desktop, keine Shell, kein Paketmanager, kein Benutzerkonto.
Innen abgeschottet
Jeder Teil (der Bildschirm, die Eingabe, das Netzwerk, die Anwendung) läuft in einer eigenen Kammer und erreicht nur, was ihm freigegeben wurde. Das System ist so ausgelegt, dass ein Fehler in einem Teil dort bleibt.
Legt seinen Rechenweg offen
Es liefert die Nachweise mit, was darin steckt und was jeder Teil darf: jede Freigabe schriftlich festgehalten, jede Komponente aufgeführt, und Prüfungen, die jeder selbst ausführen kann.
Kein Kioskmodus, der ein Allzwecksystem auf eine App abriegelt und alles andere an Ort und Stelle lässt. Kein Einzelbenutzer-Betriebssystem, das begrenzt, wer einen Computer nutzt, nicht, was darin steckt.
Was fehlt
Weniger Software. Mit Absicht.
Die meisten dedizierten Geräte betreiben ein Allzwecksystem mit einer Anwendung obendrauf, und alles andere steckt weiterhin darunter. NoWayOS beginnt bei der Aufgabe, fügt nur hinzu, was sie braucht, und lässt den Rest weg. Das ist der Unterschied.
| Ein typisches abgeriegeltes Gerät | Ein NoWayOS-Gerät | |
|---|---|---|
| Webbrowser und JavaScript-Engine | Enthalten | Nicht eingebaut |
| Desktop und Fenstersystem | Enthalten | Nicht eingebaut |
| Shell und Kommandozeile | Enthalten | Nicht eingebaut |
| Paketmanager | Enthalten | Nicht eingebaut |
| Benutzerkonten und Logins | Enthalten | Nicht eingebaut |
| Hintergrunddienste | Enthalten | Nicht eingebaut |
| Einstellungen, um alles abzuriegeln | Enthalten | Nicht eingebaut |
| Kernel | Allzweck-Kernel: Dutzende Millionen Zeilen | seL4: rund 10.000 Zeilen |
| Treiber | Für Hardware, auf die das Gerät treffen könnte | Nur für die Hardware, die das Gerät nutzt |
| Ihre Anwendung | Enthalten | Enthalten |
Screen Compiler
Sie lieben React. Wir auch.
Sie wollen reichhaltige, moderne Oberflächen, gebaut in dem Workflow, den Sie schon kennen? Schreiben Sie Ihre Screens in React. Der Screen Compiler macht daraus native Rust-Komponenten, die direkt auf NoWayOS laufen: kein Browser, kein JavaScript, keine Webseite, die sich angreifen lässt.
- Behalten Sie Ihre Werkzeuge: Komponenten, Props, Design-Tokens und den Editor, den Sie schon nutzen.
- Echte Bausteine: Layouts, Text, Buttons, Texteingaben, Checkboxen, Radio-Gruppen, Karten, Hinweise, Fortschrittsbalken und Icons.
- Exakt oder gar nicht. Er wandelt seine Teilmenge exakt um und lehnt alles andere mit Datei, Zeile und Spalte ab. Er rät nie.
- Aufs Pixel geprüft. Jeder umgewandelte Screen wird von NoWayOS gezeichnet und mit seinem abgenommenen Bild verglichen.
<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],
)?;Gekürzt aus einem der Test-Screens des Screen Compilers und dem Rust-Code, den er daraus erzeugt.
Warum das zählt
Eine Aufgabe. Mehr braucht es nicht.
Wer einen Computer für eine einzige Sache baut, kann ihn ganz anders bauen. Das bringt es Ihnen.
Sicherer
Kein Weg, auszunutzen, was nie eingebaut wurde.
- Keine Browser-Engine, kein Fenstersystem, keine Shell, kein Paketmanager, keine Benutzerkonten. Was nicht im Image steckt, kann nicht gegen es verwendet werden.
- Bildschirm, Eingabe, Netzwerk und Ihre Anwendung leben jeweils in einer eigenen, abgeschotteten Kammer und erreichen nur, was ihnen freigegeben wurde. Das System ist so gebaut, dass ein Fehler in einem Teil in diesem Teil bleibt.
- Im Kern arbeitet seL4, das die seL4 Foundation “den vertrauenswürdigsten und schnellsten Betriebssystemkernel der Welt” nennt.
- Durchgehend Rust. Unsafe-Code steckt nur in einer Handvoll geprüfter Crates, und der Build setzt diese Liste durch.
Effizienter
Nichts im Leerlauf. Nichts im Weg.
- Keine Hintergrunddienste und kein Updater für Software, die Sie nie nutzen. Einschalten, und es geht direkt an seine eine Aufgabe.
- Jedes Byte wird beim Build festgelegt: Jeder Teil erhält eine feste Menge Speicher und kann nie mehr nehmen. Der meiste Gerätecode alloziert überhaupt nichts, und selbst der TLS-Client bekommt ein festes Budget: Ist es je aufgebraucht, hält er sauber an, statt zu wachsen.
- Eine klare, native Oberfläche, die nur neu zeichnet, was sich geändert hat, und auf günstiger Hardware wie dem Raspberry Pi 5 zu Hause ist.
Einfacher im Umgang
Eine Sprache. Ein Container. Zuerst im Emulator.
- Rust von den Treibern bis zur Benutzeroberfläche.
- Gestalten Sie Screens in React. Der Screen Compiler macht daraus beim Build natives Rust: eine moderne Oberfläche ohne Browser-Engine und ohne JavaScript auf dem Gerät. Oder schreiben Sie sie gleich in Rust.
- Die Toolchains, das seL4 Microkit SDK und QEMU kommen in festen Versionen in einem Dev-Container. Ihr Rechner braucht nur Podman und make, und Python, um einen Raspberry Pi zu steuern.
Leichter nachzuweisen
Jede Freigabe festgehalten. Jedes Image aufgeschlüsselt.
- Jede Capability, die ein System vergibt, steht in einer Datei, und der Build schlägt fehl, wenn die beiden nicht übereinstimmen.
- Jedes Image wird mit einer Software-Stückliste und einem Protokoll seiner seL4-Konfiguration ausgeliefert.
- Beschränkte Beweise, dass kein Nachrichtendecoder je eine Panic auslöst, überläuft oder außerhalb der Grenzen liest, dazu Fuzzing sowie Prüfungen von Lizenzen und Sicherheitshinweisen: jede davon ein Befehl, den Sie selbst ausführen können.
Wenn alles daran hängt, geben Sie ihm genau eine Aufgabe.
Manche Geräte haben Arbeit, die zu wichtig ist, um sie mit Ablenkungen zu teilen: die Steuerung eines Stromnetzes, das Gateway aus einem Wasserwerk, das Terminal in einer Leitwarte, die Grenze zwischen zwei Netzen. NoWayOS ist auf die Rolle ausgelegt, die jedes Gerät erfüllen muss, mit den Nachweisen, die Ihnen helfen zu verstehen, was darin steckt.
Nachweise statt Adjektive
Es kümmert sich nur um seine Sache. Prüfen Sie es nach.
Eine Sicherheitsaussage ist nur so gut wie die Nachweise dahinter. NoWayOS schreibt die Nachweise auf, und jeder einzelne stammt aus einem Befehl, den Sie ausführen können.
Jede Freigabe festgehalten
Die Freigabedatei jedes Systems listet jede Priorität, jeden Speicherbereich, jedes Gerät, jeden Interrupt und jeden Kanal auf, die es freigibt. Der Build schlägt fehl, wenn System und Liste nicht übereinstimmen.
Isolation, auf Scheitern getestet
Isolationstests greifen nach dem, was ihnen nicht gegeben wurde, und seL4 muss sie stoppen. Eine Variante mit absichtlich erweiterter Freigabe muss fehlschlagen, und das zeigt, dass der Test es kann.
Jedes Image aufgeschlüsselt
Eine CycloneDX-Software-Stückliste für jedes Image: der Kernel, der Loader, jede Schutzdomäne und die Crates darin, jeweils mit ihrem Hash.
Gates außer Reichweite
Die Prüfungen, die jeder Beitrag bestehen muss, liegen in Defence Agent, einem eigenen öffentlichen Repository, und ein Pull-Request, der ein Gate berührt, wird für den Maintainer markiert.
Offen entwickelt
Vier Projekte. Jedes mit einer Aufgabe.
Alle vier sind Open Source und werden offen in der NoWayOS-Organisation auf GitHub entwickelt. Klonen Sie sie, bauen Sie sie und prüfen Sie jede Zeile selbst.
NoWayOS
Das Single Purpose OS.
Muster für Schutzdomänen auf seL4 und Microkit, typisierte Nachrichten, Treiber, Netzwerk und eine native Benutzeroberfläche, mit dem Dev-Container und den Prüfungen, mit denen jedes NoWayOS-Repository baut.
- Status
- In Entwicklung
- Lizenz
- MIT OR Apache-2.0
Screen Compiler
In React gestalten. Natives Rust ausliefern. Kein Browser auf dem Gerät.
Wandelt React-Screens, geschrieben in TSX in einer deklarierten Teilmenge, in Rust für die Benutzeroberfläche von NoWayOS um. Er läuft beim Build, auf Ihrem Rechner oder in der CI, und wird nie mit ausgeliefert.
- Status
- In Entwicklung: Teilmenge v0 und die ersten Teile von v1
- Lizenz
- MIT
Showcase
Sichere Anwendungen, die Sie auf einem Raspberry Pi ausführen können.
Ein Baukasten für sichere Selbstbedienungsbildschirme, eine Referenzanwendung als Grundlage und ein Launcher mit Beispielen unter fiktiven Marken, in den der Raspberry Pi 5 bootet.
- Status
- Frühes Stadium, nicht für den Einsatz geeignet
- Lizenz
- MIT OR Apache-2.0
Defence Agent
Die Gates, die jeder Beitrag passieren muss, außer Reichweite des Pull-Requests.
Jedes Sicherheits-Gate, das eine Änderung an den offenen Projekten von NoWayOS passieren muss, schriftlich festgehalten, mit der Bedrohung, auf die es antwortet, und mit der Angabe, wer es ändern darf, dazu der Agent, der die Gates ausführt. Ein Pull-Request ändert oder liefert nie selbst, was über ihn urteilt.
- Status
- Öffentlich: die Gates schriftlich festgehalten; der Agent und seine Werkzeuge folgen als Nächstes
- Lizenz
- MIT OR Apache-2.0
Kommerzielle Partner
Kommerzielle Produkte, gebaut auf NoWayOS.
Adappt.ai, der Sponsor von NoWayOS, ist sein erster kommerzieller Partner. Adappt.ai baut zwei kommerzielle Produkte auf NoWayOS, und beide sind in Entwicklung.
Möchten Sie kommerzieller Partner werden? E-Mail an partners@nowayos.com
- Remote Desktop
- Ein gehärteter Blick. Eine sichere Station für einen entfernten Windows-Desktop, darauf ausgelegt, die Verbindung in einer eigenen Kammer abzuschotten und die Zugangsdaten außerhalb ihrer Reichweite zu halten.
- Data Diode
- Es gibt keinen Weg zurück. Eine Einweg-Grenze, um Daten aus einem geschützten Netz herauszubringen, ausgelegt rund um eine Verbindung, die Licht nur in eine Richtung trägt.
Wo es steht
Läuft heute. Noch nicht fertig.
NoWayOS ist in Entwicklung und noch nicht reif für den Produktiveinsatz, und seine APIs werden sich ändern. Das läuft heute, und das kommt als Nächstes.
- In QEMU
- Mehr als fünfzig Systeme booten und prüfen ihre eigene Ausgabe, von einer ersten Schutzdomäne über den Netzwerkstack, der eine DHCP-Lease bezieht, und den Fail-safe-Zustand des Supervisors bis zu einer klickbaren Benutzeroberfläche.
- Auf dem Raspberry Pi 5
- Die Benutzeroberfläche auf einem HDMI-Bildschirm, USB-Tastatur und -Maus, Timer, der Watchdog und der Reset durch den Supervisor laufen alle auf dem Board. Weitere Teile seiner Hardware werden gerade in Betrieb genommen.
- Was noch kommt
- Secure Boot, signierte Updates, die auf dem Gerät eingespielt werden, und Industriehardware (NXP i.MX8).
- Die Beweise von seL4
- Jedes System läuft auf seL4, aber noch kein NoWayOS-Image nutzt eine Konfiguration, die die abgeschlossenen Beweise von seL4 abdecken. Jedes Image hält fest, welche Konfiguration es nutzt.
Die Arbeit verfolgen
Ein Zweck. Viel zu entdecken.
Beginnen Sie mit dem Design, prüfen Sie die Nachweise, oder bauen Sie Ihr erstes System mit den Entwicklerleitfäden. Diese Website hält sich übrigens an dieselbe Regel: keine Skripte, keine Cookies, sonst nichts zu tun.