Fragen, klar beantwortet.

Das Single Purpose OS: ein Betriebssystem für dedizierte Geräte, etwa die Steuerungen von Strom- und Wassernetzen, Terminals in Leitwarten und Einweg-Datendioden, gebaut für die eine Aufgabe jedes Geräts. Sie schreiben die Anwendung des Geräts in Rust, und NoWayOS baut sie, mit genau den Treibern, die sie nutzt, auf den Mikrokernel seL4. Das Image enthält genau das und sonst nichts: keine Browser-Engine, kein Fenstersystem, keine Shell, keinen Paketmanager, kein Benutzerkonto.

Ein Computer, der sonst nichts zu tun hat.

Ein Betriebssystem, gebaut für die eine Aufgabe eines Geräts, statt für alles gebaut und dann auf eine Sache abgeriegelt. Drei Dinge machen ein Betriebssystem zu einem Single Purpose OS:

• Für eine Aufgabe gebaut. Sein Image enthält die Anwendung, die Treiber, die diese Anwendung nutzt, und den Kernel, sonst nichts: keinen Browser, keinen Desktop, keine Shell, keinen Paketmanager, kein Benutzerkonto.
• Innen abgeschottet. Jeder Teil 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.

Ein Single Purpose OS ist kein Kioskmodus, der ein Allzwecksystem auf eine App abriegelt und alles andere an Ort und Stelle lässt, und kein Einzelbenutzer-Betriebssystem, das begrenzt, wer einen Computer nutzt, statt was darin steckt. NoWayOS ist ein Single Purpose OS: ein Computer, der sonst nichts zu tun hat.

Weil es keinen Weg gibt, auszunutzen, was nie eingebaut wurde. Der Name handelt davon, was in einem Gerät fehlt, und ist kein Versprechen, dass mit dem, was drin ist, nie etwas schiefgehen kann. Was eingebaut ist, kann immer noch Fehler haben; unsere Aussagen lauten: Davon gibt es viel weniger, und ein Fehler bleibt in seiner Kammer.

Abriegeln heißt sicher durch Konfiguration: Browser, Desktop und Shell sind hinter den Einstellungen weiterhin da, müssen weiterhin gepatcht werden, und ein einziger Fehler kann alle Einstellungen auf einmal umgehen. NoWayOS ist sicher durch Konstruktion: Diese Teile wurden nie in das Gerät eingebaut, und was bleibt, läuft in abgeschotteten Kammern; das System ist so ausgelegt, dass ein Fehler in einem Teil in diesem Teil bleibt.

Nein. NoWayOS ist in Entwicklung, und jede API ist vorläufig und wird sich ändern. Mehr als fünfzig Systeme booten und prüfen sich selbst in QEMU, und Benutzeroberfläche, USB-Tastatur und -Maus, Timer, Watchdog und Supervisor laufen auf einem Raspberry Pi 5. Secure Boot, signierte Updates, die auf dem Gerät eingespielt werden, und Produktionshardware kommen erst noch.

Ja. NoWayOS, das Showcase und Defence Agent stehen nach Ihrer Wahl unter MIT OR Apache-2.0, der Screen Compiler unter MIT. Alle vier sind öffentlich, in der NoWayOS-Organisation auf GitHub: Sie können sie klonen, bauen und ein Issue eröffnen.

Nein, und wir achten darauf, das nicht nahezulegen. NoWayOS läuft auf seL4, das maschinengeprüfte Beweise für Korrektheit und Sicherheit für bestimmte Konfigurationen auf der Hardware von NoWayOS hat. NoWayOS nutzt die Mixed-Criticality-Konfiguration von seL4, deren AArch64-Beweise noch in Arbeit sind; daher liegt heute kein NoWayOS-Image innerhalb der abgeschlossenen Beweise von seL4. Der eigene Code von NoWayOS ist von den Beweisen von seL4 überhaupt nicht abgedeckt; er stützt sich auf Rust, Isolation, Tests und eigene beschränkte Beweise. Jedes Image hält seine genaue seL4-Konfiguration fest (Sicherheit).

Nein. Die Sicherheit von NoWayOS beruht auf seinem Design, nicht auf Geheimhaltung: auf dem, was weggelassen wird, und auf den Kammern um das, was bleibt. Offenheit erlaubt es jedem, die Aussagen zu prüfen, die Nachweise selbst zu erzeugen und zu melden, was er findet.

Das System ist so ausgelegt, dass sie in der Kammer bleibt, in der sie steckt, was den Schaden begrenzt, während eine Korrektur entsteht; und mit viel weniger Code gibt es viel weniger zu korrigieren. Korrekturen sollen als signierte Updates mit sicherem Rückfall kommen: Das ist entworfen, aber noch nicht gebaut. Um eine Schwachstelle zu melden, schreiben Sie bitte vertraulich, wie es die SECURITY.md jedes Repositorys beschreibt, und nicht in einem öffentlichen Issue.

Nicht in ihrer jetzigen Form. NoWayOS führt Anwendungen aus, die dafür in Rust geschrieben sind; Linux- oder Windows-Programme oder eine Web-App kann es nicht ausführen, weil nichts von dem eingebaut ist, was sie brauchen. Die Screens sind der einfache Teil: React-Screens, die in der unterstützten Teilmenge des Screen Compilers geschrieben sind, werden beim Build in natives Rust umgewandelt. Die Logik der Anwendung wird als NoWayOS-Schutzdomänen neu gebaut.

Nein. Genau darum geht es ja. Auf einem NoWayOS-Gerät gibt es keine Browser-Engine, keine WebView und kein JavaScript. Screens sind natives Rust, gezeichnet von der eigenen kleinen Benutzeroberfläche von NoWayOS, und lassen sich trotzdem in React gestalten und beim Build umwandeln.

Auf der AArch64-Maschine von QEMU, wo jedes System zuerst bootet, und auf dem Raspberry Pi 5, dem günstigen Referenzboard. Die i.MX8-Familie von NXP ist die vorgesehene Produktionshardware, mit einem Hardware-Vertrauensanker; sie wird noch nicht unterstützt. Um NoWayOS zu bauen, brauchen Sie Podman (oder Docker) und make: Es wird auf Apple Silicon entwickelt, und x86-64-Hosts sind noch nicht getestet.

Klonen Sie das Repository nowayos, führen Sie einmal make container aus, dann make demo: Die gescriptete Sitzung der klickbaren Demo läuft auf Ihrem Rechner, jedes Frame wird geprüft, und Hardware brauchen Sie keine. make qemu-test SYSTEM=hello bootet anschließend seL4 in QEMU. Erste Schritte führt Sie Schritt für Schritt hindurch.