Das NoWayOS-Journal

React rein, Rust raus

2026-11-13T00:00:00Z

Moderne Oberflächen werden in React entworfen. Deshalb liefern sehr viele dedizierte Geräte, vom Bedienfeld bis zum Fahrkartenautomaten, eine komplette Browser-Engine aus, eines der größten und am häufigsten angegriffenen Programme überhaupt, um ein paar Schaltflächen und die Worte „Touch Start to begin“ zu zeichnen.

Wir wollten den modernen Design-Workflow ohne den Browser. Also haben wir den Screen Compiler gebaut.

Den Screen in React schreiben

Ihre Designer und Frontend-Entwickler behalten ihre Werkzeuge: Komponenten, Props, Design-Tokens, ihren Editor. Sie schreiben den Screen in TSX (dieser hier ist gekürzt aus einem der Test-Screens des Screen Compilers):

<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>

Schlichtes Rust ausliefern

Zur Build-Zeit, auf Ihrem Rechner oder in der CI, macht der Screen Compiler daraus Rust für die UI-Laufzeit von 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>

Jede Zeile verweist auf das TSX zurück, aus dem sie stammt. Das Gerät bekommt diesen Code und sonst nichts: keine JavaScript-Engine, keinen Browser, keine Webseite, die sich angreifen ließe. Der Screen Compiler selbst wird nie ausgeliefert.

Exakt oder gar nicht

Ein Konverter, der rät, ist ein Konverter, dem Sie nicht trauen können. Der Screen Compiler konvertiert seine deklarierte Teilmenge von TSX exakt und lehnt alles andere ab, mit Datei, Zeile und Spalte. Er nähert nie an. Das Rust, das er schreibt, enthält kein unsafe, kein unwrap und kein panic.

Dann wird jeder konvertierte Screen vom Renderer von NoWayOS gezeichnet und Pixel für Pixel mit seinem freigegebenen Bild verglichen. Bewegt sich ein einziges Pixel, sagt der Build es.

Wo er steht

Der Screen Compiler ist in Entwicklung: Seine erste Teilmenge ist gebaut, die nächste ist in Arbeit. Er ist Open Source unter MIT, auf GitHub neben NoWayOS. Wenn Ihr Team in React entwirft und Geräte baut, auf die es ankommt, würden wir gern von Ihnen hören.

Das Backup, das keine Kopie war

2026-11-13T00:00:00Z

Jeder weiß, dass man ein Backup haben sollte. Weniger Leute stellen die unbequeme Anschlussfrage: ein Backup wovon genau?

Fünf Alarme

Am 20. Juli 1969 war die Mondlandefähre von Apollo 11 wenige Minuten von der Mondoberfläche entfernt, als ihr Lenkcomputer einen Alarm auslöste, zu dem die Besatzung bei der Flugleitung nachfragen musste. Dann noch einen. Fünf insgesamt, auf dem letzten Stück des Abstiegs.

Der Computer war überlastet. Was er dann tat, gehört zu den großen Ingenieurleistungen dieser Geschichte: Jedes Mal startete er neu, ließ die Arbeit fallen, die warten konnte, und nahm die Arbeit, die nicht warten konnte, sofort wieder auf. Die Landung ging weiter.

Das ist der Teil, den alle erzählen. Der Teil, der sich als Nächstes zu erzählen lohnt, geschah am Tag darauf.

Das zweite System

Die Mondlandefähre führte ein zweites Lenksystem mit, und es war keine Ersatzkopie des ersten. Ein anderes Unternehmen hatte es gebaut, nach einem anderen Prinzip. Das Hauptsystem hielt seine Orientierung mit einer Plattform, die frei in kardanischen Rahmen schwang. Das zweite hatte gar keine solchen Rahmen: Seine Sensoren waren fest mit dem Raumfahrzeug verschraubt, und wo oben war, rechnete es aus.

Es war dazu da, die Besatzung zurück in die Umlaufbahn zu fliegen, falls das Hauptsystem je ausfiele. Während der Landung wurde es nicht gebraucht.

Dann, auf dem Rückweg zum Andocken an das Kommandomodul, brachte eine Folge von Manövern die Plattform des Hauptsystems in die eine Stellung, mit der eine kardanisch gelagerte Plattform nicht zurechtkommt, und es verlor seine Lagereferenz. Die Besatzung schaltete auf das zweite System um, um das Raumfahrzeug stabil zu halten, und dockte an.

Das zweite System hätte nicht auf dieselbe Weise versagen können. Es hatte das Bauteil nicht.

Zweimal dasselbe

Nun die andere Geschichte. 1996 hob die erste Ariane 5 mit zwei Trägheitsreferenzsystemen ab, die ihr sagten, wohin sie zeigte: eines in Betrieb, eines in Bereitschaft. Sie waren identisch, bis hin zur Software.

Nach siebenunddreißig Sekunden wurde eine Zahl in dieser Software zu groß für den Platz, der für sie vorgesehen war. Das Gerät in Bereitschaft blieb stehen. Das Gerät in Betrieb, auf dem derselbe Code auf demselben Flug lief, blieb ebenfalls stehen. Der Bericht der Untersuchungskommission ist öffentlich, und er ist unverblümt: Es gab nichts, worauf man hätte umschalten können, weil das Backup bereits denselben Weg gegangen war.

Zwei Kopien. Ein Fehler. Nichts mehr übrig.

Wie Ingenieure das nennen

Ein Fehler, der ein System und seinen Ersatz gemeinsam ausschaltet, ist ein Ausfall aus gemeinsamer Ursache. Die Abwehr dagegen ist diversitäre Redundanz: ein zweites System, das so anders gebaut ist, dass das, was das erste stoppt, im zweiten nicht steckt.

Das Space Shuttle flog so. Auf vier seiner Flugcomputer lief die Software eines Unternehmens; auf dem fünften lief Software, die ein anderes getrennt davon geschrieben hatte. Vier Kopien schützen vor einem Computer, der kaputtgeht. Vor einem Programm, das falsch ist, schützen sie nicht, denn auf allen vieren läuft es.

Umsonst ist das nicht. Der erste Start des Shuttle wurde abgesagt, als sich der fünfte Computer und die anderen vier nicht auf die Zeit einigen konnten. Zwei Entwürfe sind mehr Arbeit als einer, und man muss sie zusammenbringen.

Wo NoWayOS ins Spiel kommt

Die meisten dedizierten Geräte laufen heute mit einem von sehr wenigen Allzweck-Betriebssystemen. Ihre Backups auch. Wenn in einer Browser-Engine, einem Desktop oder einem Kernel mit Dutzenden Millionen Zeilen eine Schwachstelle auftaucht, oder wenn ein fehlerhaftes Update hinausgeht, dann taucht sie überall auf, wo diese Software läuft, am selben Tag.

Ein NoWayOS-Gerät ist im Innern anders. Sein Kernel ist seL4, etwa 10.000 Zeilen. Alles von uns darüber ist in Rust geschrieben. Es hat keine Browser-Engine, keinen Desktop und keine Shell, also steckt eine Schwachstelle in einem davon nicht in ihm.

Das heißt: NoWayOS muss nicht ersetzen, was Sie betreiben, um nützlich zu sein. Es kann daneben stehen: als zweiter Weg, eine wesentliche Aufgabe zu erledigen, nach einem anderen Prinzip gebaut.

Was es nicht leistet

Diversität hat Grenzen, und wir möchten, dass Sie sie von uns hören.

Sie gibt einem NoWayOS-Gerät andere Fehler, nicht keine. Sie hilft nicht bei dem, was zwei Systeme teilen: der Stromversorgung, dem Netzwerk, den Diensten dahinter oder einem Irrtum darüber, was die Aufgabe eigentlich sein sollte. Und einige Open-Source-Bestandteile von NoWayOS werden auch in anderer Software verwendet. Deshalb führt jedes Image jede Komponente auf, die es enthält, damit Sie nachlesen können, was es mit dem System daneben gemeinsam hat.

NoWayOS ist in Entwicklung; dies ist also eine Rolle, für die es ausgelegt ist, und noch keine, die es ausgefüllt hat. Die Sicherheitsseite sagt, worauf sie beruht.

Die Ingenieure von Apollo nahmen kein zweites System mit, weil sie erwarteten, dass das erste versagt. Sie nahmen es mit, weil sie nicht beweisen konnten, dass es nicht versagt, und sie sorgten dafür, dass das, was das erste stoppt, im zweiten nichts Vertrautes vorfindet.

Wir greifen unseren eigenen Build bei jeder Änderung an

2026-11-13T00:00:00Z

Hier ist eine unbequeme Frage an jeden Sicherheitstest: Ist er je fehlgeschlagen? Ein Test, der nie fehlgeschlagen ist, besteht vielleicht, weil das System in Ordnung ist, oder weil der Test überhaupt nichts sehen kann. Von außen sieht beides genau gleich aus.

Deshalb testet NoWayOS seine Sicherheit nicht nur. Es greift sie an, bei jeder Änderung, und prüft, dass die Angriffe aufgefangen werden.

Nach dem greifen, was einem nicht gehört

Jeder Teil eines NoWayOS-Systems läuft in seiner eigenen Kammer auf seL4 und hält nur, was ihm freigegeben wurde. Die Isolationstests schicken absichtlich Sonden über diese Grenzen. Eine liest eine Adresse, die ihr nie gegeben wurde. Eine schreibt auf eine Seite, die sie nur lesen darf. Eine, die genau das hält, was die Benutzeroberfläche hält, versucht, die Steuerseite der Anzeige zu beschreiben, die die Oberfläche nur lesen darf. Eine weitere, die genau das hält, was der Netzwerk-Client hält, versucht, in den Speicher des Netzwerktreibers zu schreiben.

seL4 muss jede einzelne stoppen, und ein unbeteiligter Teil muss unberührt weiterlaufen.

Ein Test, der fehlschlagen muss

Dann kommt die Wendung. Neben dem Isolationstest der Benutzeroberfläche steht eine Variante, bei der eine Freigabe absichtlich erweitert wurde: Der Stellvertreter der Oberfläche bekommt die private Seite der Anzeige. Der Test dieser Variante muss fehlschlagen. Würde er je bestehen, wäre der Isolationstest blind, und der Build würde es sagen.

Derselbe Gedanke zieht sich durch die übrigen Prüfungen. Jeder Decoder für Nachrichten zwischen den Teilen hat beschränkte Beweise aus dem Model Checker Kani, dass er nie in Panic gerät, nie überläuft und nie außerhalb der Grenzen liest. Mutationsprüfungen machen die Decoder dann absichtlich kaputt, um zu zeigen, dass die Beweise es merken. Jeder Parser für Eingaben von außen wird mit feindseligen Daten gefuzzt.

All das gehört zu make ci, dem Gate, das jede Änderung passieren muss. Die Isolationstests laufen jedes Mal; ein Beweis oder ein Fuzz-Lauf wird wiederholt, sobald sich der Code ändert, den er abdeckt.

Gates außer Reichweite

Ein Gate ist nur so stark wie die Hand, die es ändern kann. Deshalb sind die Prüfungen, die jeder Beitrag zu NoWayOS bestehen muss, in Defence Agent definiert, einem eigenen öffentlichen Repository. Ein Pull Request, der ein Gate berührt, wird für den Maintainer markiert.

Defence Agent testet sich selbst auf dieselbe Weise: zwanzig präparierte Pull Requests, von denen jeder etwas versteckt, das einem Reviewer entgehen könnte. Da ist versteckter Rechts-nach-links-Text in einem Kommentar, ein Buchstabe, der gegen sein kyrillisches Ebenbild getauscht wurde, eine Abhängigkeit, die direkt aus einem Git-Repository geholt wird, ein Workflow, der nicht vertrauenswürdigen Code ausführen würde. Jeder muss aufgefangen werden, während drei echte frühere Änderungen durchgehen müssen.

Nachweise statt Adjektive

Nichts davon macht ein Gerät “unhackbar”. Das tut nichts, und wir werden es nie sagen. Was Sie bekommen, sind Nachweise: ein Protokoll dessen, was versucht wurde, was gestoppt wurde, und der Befehl, der es zeigt. Lesen Sie die Nachweise eines echten Images oder die Gates selbst.

Was ein Beweis versprechen kann

2026-11-13T00:00:00Z

Software vertraut man meist, weil sie getestet wurde. Jemand hat überlegt, was schiefgehen könnte, hat es ausprobiert und zugesehen, wie sie damit zurechtkommt. Das funktioniert gut, bis zu dem Fall, an den niemand gedacht hat.

Ein Beweis fängt am anderen Ende an. Er probiert keine Fälle durch. Er zeigt mit den Mitteln der Mathematik, dass eine Aussage für alle Fälle gilt.

Jeder Fall, nicht nur die ausprobierten

Nehmen wir ein kleines Versprechen: Dieser Code liest nie über das Ende seines Puffers hinaus. Ein Test kann ihm tausend Eingaben geben oder eine Milliarde und melden, dass keine davon ihn aus dem Tritt gebracht hat. Ein Beweis sagt etwas anderer Art: Es gibt keine Eingabe, die das schafft. Es wurde keine gefunden, und es existiert keine.

Der Preis dafür ist Strenge. Ein Beweis braucht eine exakte Aussage darüber, was der Code tun soll, seine Spezifikation, und ein Argument, das jede Zeile des Codes mit ihr verbindet. Für echte Software ist dieses Argument viel zu lang, als dass ein Mensch es mit bloßem Auge prüfen könnte. Also prüft es ein Computer.

Von der Maschine geprüft

Das bedeutet „maschinengeprüft“. Der Beweis wird vollständig ausgeschrieben, in einer Sprache, die ein Programm namens Beweisassistent lesen kann, und das Programm prüft jeden Schritt gegen die Regeln der Logik. Es wird auf Seite neunhundert nicht müde, und es glaubt niemandem etwas aufs Wort.

Die Beweise von seL4 werden so geprüft, in einem Beweisassistenten namens Isabelle/HOL. Sie sind öffentlich, und jeder kann sie erneut durchlaufen lassen.

Was die Beweise von seL4 aussagen

seL4 ist der Kernel, auf dem jedes NoWayOS-System läuft: rund 10.000 Zeilen Code, und der einzige Code mit vollständiger Kontrolle über das Gerät. Auf die Größe kommt es an. Ein Argument über zehntausend Zeilen lässt sich zu Ende führen. Ein Argument über mehrere zehn Millionen noch nicht.

Die seL4 Foundation legt die Beweise in Schichten dar:

Der Code tut, was die Spezifikation sagt, und nichts darüber hinaus. Daraus folgt eine Liste von Dingen, die der Kernel nicht tun kann: über einen Puffer hinausschreiben, einem Nullzeiger folgen, Speicher verlieren, durch null teilen.
Das Programm, das läuft, entspricht dem Code, der bewiesen wurde. Dazwischen sitzt ein Compiler, also prüft ein weiterer Beweis dessen Ausgabe.
Der Kernel kann die Teile eines Systems voneinander getrennt halten. Ein Teil kann die Daten eines anderen nicht ändern, nicht lesen und ihm die benötigten Ressourcen nicht nehmen, es sei denn, ihm wurde das Recht dazu gewährt.
Ein System kann in dem Zustand starten, für den es entworfen wurde, mit genau den Rechten, die seine Beschreibung aufführt.

Nicht jede Schicht ist für jeden Prozessor und jede Konfiguration fertig. Das ist wichtig, und wir kommen darauf zurück.

Was ein Beweis voraussetzt

Ein Beweis ist genau so weit wie seine Aussage, und er steht auf seinen Annahmen. seL4 schreibt die eigenen auf: dass sich die Hardware so verhält, wie ihr Modell es beschreibt, dass einige hundert Zeilen des hardwarenächsten Codes stimmen, dass der Code, der vor dem Start des Kernels läuft, seine Arbeit getan hat. Der Beweis der Vertraulichkeit deckt das Zeitverhalten nicht ab.

Er sagt nichts darüber, ob die Spezifikation das Richtige verlangt, und nichts über die Software oberhalb des Kernels. Ein bewiesener Kernel isoliert zuverlässig auch ein Programm, das einen Fehler enthält. Der Fehler ist immer noch da. Er kommt nur an nichts anderes heran.

Das ist keine Schwäche der Beweise. Es macht sie erst wertvoll: Sie sagen genau, was sie abdecken, also wissen Sie genau, was übrig bleibt.

Wo NoWayOS steht

Hier ist der Stand, ohne Umschweife. NoWayOS läuft auf seL4, aber kein NoWayOS-Image liegt heute innerhalb der abgeschlossenen Beweise von seL4. NoWayOS nutzt die Mixed-Criticality-Konfiguration von seL4, deren Beweise für unsere Prozessoren in Arbeit sind. Und den eigenen Code von NoWayOS haben die Beweise von seL4 nie abgedeckt. Deshalb nennen wir NoWayOS nicht “formal verifiziert”, und wir werden es auch nicht tun.

Jedes Image sagt, wo es steht. Eine Datei daneben führt die Konfiguration seines Kernels auf, Option für Option, neben derjenigen, die seL4 bewiesen hat. Sicherheit zeigt eine echte.

Kleinere Beweise aus eigener Hand

Der Code von NoWayOS bekommt seine Absicherung auf anderem Weg: Rust, Isolation, Review, Tests und Beweise von bescheidenerer Art.

Jeder Decoder der Nachrichten, die zwischen den Teilen eines Systems fließen, hat beschränkte Beweise, erstellt mit einem Model Checker namens Kani. Ein beschränkter Beweis deckt jede Eingabe bis zu einer festgelegten Größe ab, hier den längsten Datensatz, den ein Decoder annimmt. Innerhalb dieser Schranke ist er ein echter Beweis: Keine Eingabe bringt den Decoder zum Panic, zum Überlauf oder dazu, außerhalb der Grenzen zu lesen. Jenseits der Schranke sagt er nichts, und deshalb ist die Schranke die längste Eingabe, die es gibt.

Dann machen wir die Decoder absichtlich kaputt, um sicherzugehen, dass die Beweise es merken. Ein Beweis, der nicht scheitern kann, ist nicht besser als ein Test, der es nicht kann.

Die ehrliche Größe der Sache

Ein Beweis macht nichts “unhackbar”. Er macht eine Aussage wahr, in jedem Fall, unter Annahmen, die Sie nachlesen können. Wer die Aussage und die Annahmen kennt, weiß, was er hat.

Deshalb baut NoWayOS auf dem Kernel auf, der solche Beweise hat, und sagt Ihnen, Image für Image, wie weit sie reichen.

Warum ein NoWayOS-Gerät keine Shell hat

2026-11-13T00:00:00Z

Die meisten Angriffe auf ein dediziertes Gerät zielen nicht auf die Aufgabe, die es erfüllt. Sie zielen auf den Rest des Computers, auf dem es läuft: die Shell, die für die Wartung dringeblieben ist, den Fernzugriffsdienst, den niemand abgeschaltet hat, den Browser hinter der Anwendung, den Desktop, der nur einen Absturz entfernt liegt.

Dieser „Rest des Computers“ ist überall. Das Gateway, das Messwerte aus einem Wasserwerk hinausträgt, das Terminal in der Leitwarte eines Stromnetzes, die Geräte, auf die sich ein Krankenhaus verlässt, das Bedienfeld an der Seite einer Maschine, der Bildschirm in einer Bahnhofshalle: Viele von ihnen laufen mit einem Allzweck-Betriebssystem, mit einer Aufgabe obenauf und allem anderen noch darunter, per Einstellung abgeschaltet. Der Kioskmodus ist die einfachste Variante. Jede Kompromittierung besteht darin, dass jemand die eine Einstellung findet, die übersehen wurde.

Stattdessen weglassen

NoWayOS fängt am anderen Ende an. Ein NoWayOS-Image enthält die Anwendung des Geräts, die Treiber, die diese Anwendung nutzt, und den seL4-Mikrokernel. Das ist die ganze Liste.

Es gibt keine Shell, in die man fallen könnte, weil nie eine eingebaut wurde. Keinen Fernzugang, für den sich ein Passwort erraten ließe. Keinen Desktop, auf den man ausbrechen könnte. Keine Browser-Engine, die auf eine bösartige Seite wartet. Eine Einstellung für Software, die nicht da ist, kann man nicht falsch setzen.

All das betrifft das Betriebssystem. Die Anwendung darüber ist etwas anderes: Sie kann ihre Nutzer anmelden und sich bei anderen Systemen anmelden, wann immer ihre Aufgabe es verlangt. Sie sitzt nur nicht auf einem Betriebssystem, an dem sich jemand anmelden kann.

Wir nennen das ein Single Purpose OS: ein Computer, der sonst nichts zu tun hat.

Und was da ist, ist abgeschottet

Weglassen ist die eine Hälfte. Jeder Teil, der bleibt (das Netzwerk, der Bildschirm, die Eingabe, die Anwendung), läuft in einer eigenen Kammer, einer Schutzdomäne in der Sprache von seL4, und erreicht nur, was ihm freigegeben wurde. Der Netzwerktreiber bewegt Pakete. Der Anzeigetreiber zeichnet. Die Anwendung spricht mit beiden über Nachrichten fester Größe.

Jede Freigabe steht in einer Datei, ein Fakt pro Zeile, und der Build schlägt fehl, wenn System und Datei nicht übereinstimmen. Das Ganze ist so gebaut, dass ein Fehler in einem Teil in diesem Teil bleibt.

„Aber wie repariert man es ohne Shell?“

Das fragen Ingenieure zuerst, und zu Recht. Am Betriebssystem eines NoWayOS-Geräts meldet man sich nicht an: Es hat keine Konten, also gibt es niemanden, als der man sich anmelden könnte. Man baut ein neues Image und ersetzt das alte. Heute heißt das, es zu bauen und auf das Board zu laden; signierte Updates, die das Gerät prüft und die sicher zurückfallen können, sind entworfen und auf dem Weg.

Dafür bekommen Sie ein Gerät, das direkt in seine eine Aufgabe startet, mit weit weniger, das zu patchen ist, und weit weniger, das sich angreifen lässt. Für die Systeme, auf denen ein Land läuft, ist genau dieser Tausch der Sinn der Sache.

Sehen Sie selbst

Die Nachweise für ein echtes NoWayOS-Image, seine Freigabedatei, seine Stückliste und sein seL4-Konfigurationsprotokoll, stehen auf unserer Sicherheitsseite. Keine Anmeldung, kein Skript. Nur die Dateien.