Munal OS – grafisches experimentelles Betriebssystem mit WASM-Sandboxing

• Ein vollständig in Rust implementiertes grafisches experimentelles Betriebssystem, das ein Unikernel-Design und ein WASM-basiertes Sandboxing-Sicherheitsmodell verwendet
• Kernel, WASM-Engine und alle Apps sind in eine EFI-Binärdatei eingebettet und bieten so eine minimierte Struktur und eine ungewöhnliche System-Call-Schnittstelle
• Läuft in QEMU über VirtIO-basierte Treiber, wobei Eingabe, Netzwerk und GPU-Verwaltung ohne Interrupts per Polling umgesetzt sind
• Unterstützt durch eine globale Event-Loop und kooperatives Scheduling eine vereinfachte Laufzeitstruktur sowie anwendungsbezogenes Ressourcen-Monitoring
• Bietet das eigene UI-Toolkit Uitk sowie integrierte Apps (Webbrowser, Texteditor, Python-Terminal); WASM-Apps lassen sich in verschiedenen Sprachen entwickeln

---

Was ist Munal OS?

• Munal OS ist ein vollständig in Rust entwickeltes experimentelles Betriebssystem, ein Projekt, das geschaffen wurde, um neue OS-Designs zu erforschen, indem es eine auf Unikerneln basierende Architektur mit WASM-Sandboxing kombiniert
• Ziel ist es, Komplexität zu reduzieren, nur die wesentlichen Bestandteile beizubehalten und mit modernen Werkzeugen eine vereinfachte Systemstruktur zu verwirklichen

Hauptmerkmale

• Unterstützung für eine vollgrafische Umgebung und HD-Auflösung mit Maus- und Tastatur-Interface
• Sandbox-Ausführung von Apps, die den Zugriff von Benutzeranwendungen auf Kernel-Speicher blockiert
• Integrierte Netzwerktreiber und eigener TCP-Stack
• Enthält ein anpassbares UI-Toolkit (Uitk) mit verschiedenen Widgets, flexiblem Layout und Text-Rendering
• Mitgelieferte Apps: Webbrowser (DNS, HTTPS, grundlegendes HTML), Texteditor, Python-Terminal

Architektur

• Auf EFI-Binärdateien basierende Struktur

  • Läuft ohne Bootloader als EFI-Binärdatei; Kernel/WASM-Engine/Apps sind in einer einzigen Datei eingebettet
  • UEFI-Boot-Services werden so früh wie möglich beendet und abgesehen von der Systemuhr nicht weiter genutzt

• Verwaltung des Adressraums

  • Kein virtueller Adressraum, stattdessen direkte Nutzung der von UEFI hinterlassenen identity-mapped addresses
  • Keine Änderungen an den Seitentabellen. Direkter Schutz des Kernel-Speichers wird stattdessen durch WASM-Sandboxing ergänzt

• Treiber und Hardware-Unterstützung

  • Statt PS/2 oder VGA wurden PCI-Treiber direkt implementiert, die die VirtIO-1.1-Spezifikation nutzen
    • Treiber für Tastatur, Maus, Netzwerk und GPU vorhanden
  • Keine Verwendung von Interrupts, alle Treiber sind als Polling-System entworfen
  • Ausführung auf realer Hardware außerhalb von QEMU wird nicht unterstützt und erfordert weitere Entwicklung

• Event-Loop und Scheduling

  • Keine Unterstützung für Multicore/Interrupts; der gesamte Ablauf wird linear in einer einzelnen globalen Event-Loop ausgeführt
    • In jedem Loop-Zyklus werden Netzwerk-/Eingabetreiber gepollt, Desktop-UI und Apps ausgeführt und der GPU-Framebuffer aktualisiert
  • Einfache Performance-Analyse, da die Zeit pro Loop-Zyklus messbar ist
  • Apps müssen die CPU aktiv freigeben; lang laufende Aufgaben müssen explizit nachgeben
  • Basiert auf kooperativem Scheduling; eine erzwungene Beendigung fehlerhafter Apps über die fuel-limit-Funktion der Wasmi-Engine wäre möglich (noch nicht implementiert)

Struktur der Anwendungsausführung

• Die [Wasmi WASM engine] ist integriert und bietet bei der Ausführung von Apps vollständiges Sandboxing und Trennung vom Kernel
• Auf Kernel-Ebene wird eine System-Call-API bereitgestellt, über die Apps Maus-/Tastaturereignisse abfragen, TCP-Sockets nutzen oder auf den Framebuffer ausgeben können
• Die Render-Ausgabe der Apps wird vom OS auf dem Desktop zusammengesetzt und dargestellt
• Apps können auch in anderen Sprachen als Rust erstellt werden; jede Sprache ist nutzbar, solange sie WASM-Builds unterstützt
• WASI-Kompatibilität wird teilweise unterstützt. Keine vollständige Konformität, nur eine minimale Implementierung zur Nutzung wichtiger externer Abhängigkeiten
• Pro App gibt es einen dedizierten Log-Stream (ähnlich stdout), der zusammen mit der Ressourcennutzung in der Desktop-Ansicht „Audit“ eingesehen werden kann

UI-Toolkit (uitk)

• Ein eigenes Immediate-Mode-UI-Kit, das sowohl von Munal OS als auch von WASM-Apps verwendet wird
• Bietet Basis-Widgets (Buttons, Progressbar, Text-Edit, Scroll-Canvas) sowie einen Dreiecks-Rasterizer
• Einheitliches Styling auf Basis eines globalen Stylesheets, mit Unterstützung für Overwrites auf Elementebene
• Effizientes Caching-System zur Vermeidung unnötiger Neurenderings
  • Aufteilung in „Tiles“ pro Bereich, mit einem Änderungs-Erkennungsalgorithmus auf Basis der Rust-Mutability-Regeln

Build- und Laufzeitumgebung

• Build und Ausführung sind mit Rust Nightly 2025-06-01 und QEMU 10.0.0 oder neuer möglich

Wichtige Referenzen und Credits

• Rust-OS-Tutorial von Philipp Oppermann und Dokumentation aus dem OSDev Wiki
• Nutzung wichtiger Open-Source-Projekte wie Wasmi, smoltcp, Rustls und RustPython
• Verwendung verschiedener Open-Source-Schriften, Icons und Wallpaper-Ressourcen

Bedeutung und Vorteile von Munal OS

• Die Kombination aus einer einzelnen EFI-Binärdatei und innovativem Sandboxing regt zum Überdenken bestehender OS-Designparadigmen an
• Für die QEMU-Umgebung optimiert und mit einer ungewöhnlichen Polling-basierten Treiberstruktur, wodurch die Abhängigkeit von realer Hardware minimiert wird
• Transparenz bei der Verwaltung von Systemressourcen sowie hoher Lern- und Experimentierwert durch die einfache Struktur
• Großes Potenzial zur Erweiterung des WASM-App-Ökosystems ohne Einschränkungen durch Sprache oder Umgebung

[GN⁺]

Hacker-News-Kommentare

• Ich fand die Struktur interessant, bei der in jeder Iteration Netzwerk und Eingabetreiber gepollt werden, die Desktop-Oberfläche gezeichnet wird, jede aktive WASM-Anwendung einen Schritt ausführt und danach der GPU-Framebuffer geflusht wird. Ich habe im Code nachgesehen, wie das mit Wasmi umgesetzt wurde: GitHub-Code-Link. Ich möchte darauf hinweisen, dass in neueren Wasmi-Versionen (v0.45+) die Unterstützung für resumable function calls erweitert wurde, sodass bei aufgebrauchtem Fuel ein Yield möglich ist: Wasmi-Dokumentation. Da bereits Fuel Metering verwendet wird, könnte das auf Ausführungsebene ein effizienterer Ansatz sein. Ein Beispiel für die Nutzung findet sich im Wasmi-Wast-Runner-Beispiel

  • Noch einmal danke dafür, dass du Wasmi gebaut hast. Die Nachricht, dass Wasmi bei leerem Fuel yielden kann, ist wirklich spannend. In der früheren Dokumentation habe ich so eine Funktion nicht gefunden, was ich schade fand; wenn es sie damals schon gegeben hätte, wäre die Designrichtung der WASM-Apps vermutlich anders ausgefallen
  • Ich bin zwar nicht der OP, aber ich verstehe nicht ganz, warum diese Funktion hilfreich ist. Bedeutet das, dass man aus einer Funktion eine Coroutine macht, sie startet, und wenn sie während der Ausführung wegen Speichermangels fehlschlägt, kann man mehr Speicher geben und die Coroutine dann wieder resumieren? Falls ja, worin liegt dann der Unterschied zum bisherigen Verhalten? Gibt es in WASM kein try/catch? Wenn man im Fehlerzustand malloc ohnehin explizit erneut versuchen muss, ist mir der konkrete Gewinn nicht klar, deshalb bin ich etwas verwirrt
  • Ich bin begeistert, dass Wasmi schnell genug ist, um GUI-Apps auszuführen. Ich entwickle gerade eine App-Runtime für portable und gut übertragbare GUI-Anwendungen. Ich habe mich für wasm entschieden, um ein Gleichgewicht zwischen Performance und einfacher Implementierung zu finden, und hoffe, dass sich so mit effektiv nur wenigen Personen oder sogar einer Einzelperson eine Runtime relativ direkt bauen lässt. Dass eine optimierte, interpreterbasierte wasm-Runtime wie Wasmi auch GUI-Apps problemlos ausführen kann, zeigt für mich enormes Potenzial

• Da die Struktur auf VirtIO basiert, wurde erwähnt, dass Munal OS auf echter Hardware noch nicht läuft. Falls man es auf realer Hardware betreiben wollte, wäre es aus meiner Sicht auch ein interessanter Ansatz, statt eigener Treiber Linux als Bootloader zu verwenden und das Betriebssystem in einem minimalistischen Hypervisor laufen zu lassen. So ließe sich das Konzept „VirtIO ist die Plattform“ beibehalten. Für Apps WASM zu nutzen und für die Plattform VirtIO zu wählen, bewahrt diese Identität auf eine schöne Weise. Aus Sicherheitssicht wäre aber der Einsatz einer MMU nötig. Virtual Memory müsste man vom Design her zwar nicht vollständig einführen, aber allein für Schutzbits entstünden zusätzliche Komplexitäten wie Seitentabellen- und TLB-Verwaltung, was die Einfachheit etwas schwächt

  • Bei meinem letzten Hackintosh-Versuch habe ich Linux ähnlich als Bootloader und minimalistischen Hypervisor genutzt, und das hat ganz gut funktioniert. Der Nachteil ist, dass man ohne echte GPU-Ereignisse auf die von Linux gewählte Auflösung und Konfiguration festgelegt ist, was die Freiheit einschränkt. Wenn dieses OS statt eines echten OS auch als UEFI-Datei laufen könnte, wäre Grafik vielleicht schon nur mit dem UEFI-Videotreiber möglich, aber ich bin mir nicht sicher, ob sich das realistisch umsetzen lässt, wenn es zugleich echte OS-Eigenschaften haben soll

• Ein noch größerer Nachteil als die Tatsache, dass der Hauptloop die CPU nicht zu lange blockieren darf und lang laufende Aufgaben ausdrücklich yielden müssen, ist aus meiner Sicht, dass bei vielen geöffneten Apps jede einzelne langsamer wird. Ich habe selten mehr als zehn Apps gleichzeitig offen gehabt, aber aus Erfahrung mit bis zu 30 Tabs würde bei Prozessen für jedes davon der Performance-Verlust deutlich auffallen. Wenn die Hardware schnell genug ist, ist das vielleicht kein Problem, aber bei schweren Aufgaben wie etwa Video-Rendering könnte aus 1 Sekunde schnell 30 Sekunden werden. Trotzdem ist es sehr klug, beeindruckend und spannend, ein ganzes OS auf diese Weise umgesetzt zu haben

  • Solange die Apps ihre Arbeit rechtzeitig abschließen, müssen sie überhaupt nicht langsamer werden. Sie laufen, werden fertig und warten dann auf den nächsten Frame. Erst wenn die Ressourcen knapp werden und die Wartezeit auf 0 oder darunter sinkt, wird alles insgesamt langsamer; das ist nur weniger elegant als ein komplexer fairer Scheduler. Jedes Programm yieldet ausdrücklich, sobald sein Frame fertig vorbereitet ist, daher verbrauchen Apps ohne Arbeit fast keine Zeit

• Neben dem kooperativen Scheduling scheint auch die Abwehr von Spectre-Angriffen schwierig, und ich frage mich, ob ohne Virtual Memory überhaupt Effizienz möglich ist. Wenn etwa bei memory.grow in WASM der Speicher einer anderen App im Weg ist, müsste man womöglich alles per memmove verschieben. Ich frage mich, ob das praktikabel ist. Trotzdem ist es ein wirklich beeindruckendes Projekt

  • Wenn Spectre hier ein Angriffsvektor sein soll, welche Bedrohungsannahme liegt dann genau zugrunde? In der aktuellen Struktur wird jede App direkt in den Kernel kompiliert, und selbst der Webbrowser führt kein JavaScript aus, daher scheint es gar keinen Zufluss von nicht vertrauenswürdigem Code zu geben
  • Ich hätte gern eine genauere Erklärung

• Ich frage mich, wie sich solche Ansätze verändern werden, wenn wasm-Komponenten Wirklichkeit werden. Ich halte das Unikernel-Design für sehr gelungen, und auch die vielen Funktionen von Munal OS sind beeindruckend. Ich hoffe, dass wasm nicht nur für eine einzelne große App, sondern auch zum Hosten vieler kleiner Prozesse und Sub-Umgebungen genutzt wird. Mit wasi preview3 dürfte bald die Koexistenz von synchron und asynchron möglich werden, und damit hätte wasm praktisch alle Bausteine einer allgemeinen Runtime. Weiterhin schade finde ich, dass Host-Object-Bridging in der Realität so stark auf JS ausgerichtet ist, aber ich hoffe, dass das Versprechen von wasm-Komponenten – Standardisierung, Leichtgewichtigkeit, Sandboxing und Sprachkombinierbarkeit – sich in der Praxis als echte Runtime-Fähigkeit statt nur als weiteres Verteilformat zeigt. Dazu passt auch dieser Vortrag: What is a Component (and Why)

  • Wolltest du bei diesem Thema vielleicht dieses Video erwähnen: YouTube-Link?
  • Ich habe angefangen, eine Rust-App zu bauen, die SDL3 unterstützt und V8 für Skripting einbettet: Blogvorstellung. Aber ich überlege ernsthaft, das zu forken und stattdessen wasmtime oder wasmi einzubetten, damit Skripting in praktisch jeder Sprache möglich wird. Man könnte sogar Compiler mit einbetten und so eine Struktur schaffen, in der man einfach Dateien hineinwirft und direkt skripten kann. Wasmtime und wasmi sind nämlich schneller als viele andere Scripting-Engines: Vergleichsdaten. Der Nachteil ist allerdings, dass man die komplette Code-Umgebung einrichten muss, wodurch der Einstiegsvorteil von Skripten geschwächt wird. Trotzdem ist die Idee so cool, dass ich sie gern wenigstens einmal ausprobieren würde

• Im PyCon-2014-Vortrag „The Birth and Death of Javascript“ wurde eine Zukunft vorgestellt, in der asm.js – der Vorläufer des heutigen wasm – ein OS-Sandboxing umsetzt. Das wirkt auf mich sehr ähnlich zum Kern dieses Projektdesigns, daher frage ich mich, ob das ein Einfluss war: Vortragslink

  • Ich halte es für wahrscheinlicher, dass eher Microsofts Forschungs-OS Midori Einfluss hatte: Midori-Vorstellung

• Ich war überrascht zu sehen, dass dieses OS sogar einen eigenen Webbrowser eingebaut hat: Webbrowser-Quellcode. Im Demo-Video kann man auch sehen, wie Hacker News gerendert wird

  • Bevor sich im Webbrowser Funktionen wie JS und CSS immer weiter ausgebreitet haben, konnte man mit so kleinen Browsern das Web mit minimalen Abhängigkeiten immerhin betrachten. Heute ist es eher schade, dass man damit den Großteil des Webs nicht mehr sinnvoll nutzen kann. Ich finde, man müsste das inhaltsorientierte Web und das app-orientierte Web klarer trennen. Für das Inhalts-Web bräuchte man nur einen sehr einfachen HTTP-Client und einen HTML-Parser, und Web-Apps kämen ähnlich wie dieses OS mit wasm plus wenigen Hardware-APIs aus. Allerdings wäre UDP-Unterstützung zwingend nötig

• Ich finde das erstaunlich und frage mich zugleich, ob so eine Struktur die Zukunft des OS sein könnte. Schon das README ist ziemlich spannend. Mich würde interessieren, warum statt wasmi nicht wasmtime gewählt wurde. Ich würde dieses OS gern selbst in einer VM ausprobieren und hätte sogar Lust, meine GUI-Bibliothek nach Munal zu portieren

  • Ich habe die Erfahrung gemacht, dass es viel zu schwierig war, wasmtime im no_std-Modus zu bauen, und mich deshalb letztlich für wasmi entschieden
  • Dazu noch der Scherz, dass bei Gesprächen über die Zukunft moderner OS-Strukturen natürlich auch SPECTRE und MELTDOWN mit am Tisch sitzen
  • Da die App-Isolation hier über Virtualisierung erfolgt, erlebt man in Qubes OS gewissermaßen schon heute eine ähnliche Zukunft. Dort ist die App-Isolation sehr konsequent umgesetzt

• Seit den Zeiten von Xerox PARC wird immer wieder versucht, „Userspace in Bytecode zu verwandeln“, und aus Marktsicht waren eigentlich nur IBM i, ChromeOS und Android wirklich erfolgreich. Trotzdem ist dieses Projekt großartig, und ich hoffe, dass es Erfolg hat

  • Es fällt inzwischen fast schon als Muster auf, dass du in jedem WebAssembly-Thread wieder von alten Bytecode-VMs anfängst. Die Einschätzung hat immer denselben Tonfall, aber in Entwickler-Communities sind vielfältige Experimente und neue Ansätze nun einmal unvermeidlich. Statt nur das grobe Muster zu erkennen, würde ich mir mehr konkrete Detailmeinungen wünschen
  • Das Konzept hat so offensichtliche Vorteile, dass es zwangsläufig immer wieder neue Versuche geben wird, bis es sich einmal richtig als Standard etabliert. Gerade darin unterscheidet sich wasm deutlich etwa von der JVM, weil es genau dieses Ziel tatsächlich verfolgt
  • ChromeOS ist letztlich nur ein Browser und verwendet V8 eher beiläufig, und ich glaube, Android wäre mit fast jeder technischen Grundlage erfolgreich gewesen. Der Erfolg dieser beiden Systeme lag eher am Preis als an der Technik

• Schon das Design dieses Client-OS ist erstaunlich. Ich denke, so eine Struktur wäre auch auf Servern sofort praktisch nutzbar. Wenn man den Kernel extrem klein hält und nur eine einzige laufende App übrig lässt, kann man unnötige Sicherheitsgrenzen reduzieren. Ein Key/Value-Store würde etwa gut zu so einer Struktur passen. Mich würde interessieren, ob man mit diesem I/O-Modell gute Netzwerkperformance erreicht und ob es beim Hosting von WASM spezielle Techniken geben könnte, um unnötige Speicherkopien zu vermeiden