Munal OS - un système d’exploitation expérimental graphique avec sandboxing WASM

• Système d’exploitation expérimental graphique entièrement implémenté en Rust, utilisant une conception unikernel et un modèle de sécurité par sandboxing basé sur WASM
• Le noyau, le moteur WASM et toutes les applications sont intégrés dans un binaire EFI, offrant une structure minimale et une interface d’appels système originale
• Fonctionne dans QEMU via des pilotes basés sur VirtIO, avec la gestion des entrées, du réseau et du GPU implémentée en polling sans interruptions
• Prend en charge une structure de fonctionnement simplifiée et le suivi des ressources par application via une boucle d’événements globale et un ordonnancement coopératif
• Fournit son propre toolkit UI Uitk ainsi que des applications intégrées (navigateur web, éditeur de texte, terminal Python), avec la possibilité de développer des applications WASM dans divers langages

---

Qu’est-ce que Munal OS

• Munal OS est un système d’exploitation expérimental entièrement développé en Rust, créé pour explorer une nouvelle conception d’OS en combinant une architecture de type unikernel et le sandboxing WASM
• Il vise à réduire la complexité et à ne conserver que les éléments essentiels afin de réaliser une structure système simplifiée avec des outils modernes

Principales caractéristiques

• Prise en charge d’un environnement entièrement graphique et de la résolution HD, avec interface souris et clavier
• Exécution des applications en sandbox, empêchant les applications utilisateur d’accéder à la mémoire du noyau
• Pilote réseau et pile TCP maison intégrés
• Inclut un toolkit UI personnalisable (Uitk), avec divers widgets, des layouts flexibles et la prise en charge du rendu de texte
• Applications fournies par défaut : navigateur web (prise en charge de DNS, HTTPS et HTML de base), éditeur de texte, terminal Python

Architecture

• Structure basée sur un binaire EFI

  • Fonctionne sous forme de binaire EFI sans bootloader, avec le noyau, le moteur WASM et les applications intégrés dans un seul fichier
  • Les services de boot UEFI sont arrêtés le plus rapidement possible et ne sont plus utilisés ensuite, à l’exception de l’horloge système

• Gestion de l’espace d’adressage

  • N’utilise pas d’espace d’adressage virtuel et exploite directement les adresses identity-mapped laissées par l’UEFI
  • Aucune modification des tables de pages. La protection directe de la mémoire du noyau est compensée par le sandboxing WASM

• Pilotes et prise en charge matérielle

  • Au lieu de PS/2 ou VGA, implémente directement des pilotes PCI exploitant la spécification VirtIO 1.1
    • Fournit des pilotes pour le clavier, la souris, le réseau et le GPU
  • N’utilise pas d’interruptions ; tous les pilotes sont conçus selon un modèle de polling
  • L’exécution sur matériel réel hors de QEMU n’est pas prise en charge et nécessitera des développements supplémentaires

• Boucle d’événements et ordonnancement

  • Pas de prise en charge du multicœur ni des interruptions ; l’ensemble du système s’exécute de manière linéaire dans une unique boucle d’événements globale
    • À chaque itération, le système interroge les pilotes réseau/entrée, exécute l’interface desktop et les applications, puis met à jour le framebuffer du GPU
  • Facilite l’analyse des performances, avec la possibilité de mesurer le temps de chaque cycle de boucle
  • Les applications doivent libérer explicitement le CPU ; les tâches longues doivent céder la main de façon explicite
  • L’ordonnancement est coopératif, mais il serait possible de forcer l’arrêt d’applications défaillantes via la fonction de limite de fuel du moteur Wasmi (non implémenté)

Structure d’exécution des applications

• Le [moteur WASM Wasmi] est intégré et fournit une sandbox complète avec séparation du noyau lors de l’exécution des applications
• Le noyau fournit une API d’appels système, permettant aux applications de lire les événements souris/clavier, d’utiliser des sockets TCP, d’écrire dans le framebuffer, etc.
• Le rendu des applications est composé par l’OS puis affiché sur le desktop
• Il est possible de créer des applications dans d’autres langages que Rust ; toute cible capable de produire du WASM peut être utilisée
• La compatibilité WASI est partielle. Elle n’est pas complète et ne comprend qu’une implémentation minimale pour l’utilisation des principales dépendances externes
• Chaque application dispose d’un flux de logs dédié (similaire à stdout), consultable avec l’utilisation des ressources dans la vue « audit » du desktop

Toolkit UI (uitk)

• Kit UI en mode immédiat maison, utilisé à la fois par Munal OS et les applications WASM
• Fournit des widgets de base (boutons, barre de progression, édition de texte, canvas défilant) ainsi qu’un rasterizer de triangles
• Style unifié basé sur une feuille de style globale, avec possibilité de surcharge au niveau de chaque élément
• Système de cache efficace pour éviter les rerenderings inutiles
  • Découpage en « tuiles » par zone et algorithme de détection des changements basé sur les règles de mutabilité de Rust

Environnement de build et d’exécution

• Peut être compilé et exécuté avec Rust Nightly 2025-06-01 et QEMU 10.0.0 ou version ultérieure

Principales références et crédits

• Tutoriel Rust OS de Philipp Oppermann et documentation de l’OSDev Wiki
• Utilise plusieurs grands projets open source comme Wasmi, smoltcp, Rustls et RustPython
• Utilise également diverses polices, icônes et ressources de fond d’écran open source

Signification et atouts de Munal OS

• La combinaison d’un binaire EFI unique et d’un sandboxing innovant invite à repenser les paradigmes classiques de conception des OS
• Optimisé pour l’environnement QEMU et doté d’une architecture de pilotes originale basée sur le polling, il minimise la dépendance au matériel système réel
• Offre une grande transparence dans la gestion des ressources système et une forte valeur pédagogique et expérimentale grâce à sa structure simple
• Présente un fort potentiel d’extension de l’écosystème d’applications WASM, sans contrainte particulière de langage ou d’environnement

[GN⁺]

Commentaires Hacker News

• Je trouve intéressant que l’architecture consiste, à chaque itération, à sonder le réseau et les pilotes d’entrée, dessiner l’interface desktop, exécuter une étape de chaque application WASM active, puis vider le framebuffer GPU. J’ai regardé le code pour voir comment cela a été implémenté avec Wasmi : lien vers le code GitHub. Je voudrais signaler que dans les versions récentes de Wasmi (v0.45+), les appels de fonction reprenables ont été étendus pour permettre un yield quand le fuel est épuisé : lien vers la documentation Wasmi. Comme le fuel metering est déjà utilisé, cela pourrait être une méthode plus efficace à l’étape d’exécution. Un exemple d’utilisation est visible dans l’exemple Wasmi Wast runner

  • Merci encore d’avoir créé Wasmi. La possibilité de faire un yield quand le fuel tombe à zéro est vraiment fascinante. Je regrettais de ne pas avoir trouvé cette fonctionnalité dans l’ancienne documentation ; si elle avait existé à l’époque, l’orientation de conception des applis WASM aurait sans doute été différente
  • Je ne suis pas l’OP, mais je ne comprends pas bien en quoi cette fonctionnalité aide. Est-ce que cela veut dire qu’on peut créer une coroutine à partir d’une fonction, la démarrer, puis si elle échoue en cours d’exécution faute de mémoire, lui fournir plus de mémoire et reprendre ensuite la coroutine ? Si c’est le cas, je me demande en quoi cela diffère du comportement existant. Et WASM n’a pas de try/catch ? Si, depuis un état d’échec, il faut explicitement retenter le malloc, j’ai du mal à voir ce qu’on y gagne réellement
  • Je suis enthousiaste à l’idée que Wasmi soit assez rapide pour faire tourner des applis GUI. Je développe un runtime applicatif pour créer des applis GUI très portables et facilement transposables. J’ai choisi wasm pour l’équilibre entre performances et simplicité d’implémentation, et j’espère qu’un runtime puisse réellement être monté rapidement par une équipe de quelques personnes, voire une seule. Le fait qu’un runtime wasm interprété et optimisé comme Wasmi puisse exécuter sans difficulté des applis GUI me semble très prometteur

• Comme l’architecture dépend de VirtIO, Munal OS ne fonctionne pas encore sur du matériel réel. Pour le faire tourner sur du vrai hardware, au lieu d’ajouter directement des pilotes, utiliser Linux comme bootloader puis exécuter l’OS dans un hyperviseur minimal serait aussi une approche intéressante. Cela permettrait de conserver le concept selon lequel « VirtIO est la plateforme ». Choisir WASM pour exécuter les applis et VirtIO pour la plateforme donne une identité forte. Mais du point de vue sécurité, il faudrait utiliser la MMU. La conception n’impose pas forcément d’introduire la mémoire virtuelle, mais il faudrait tout de même gérer des tables de pages, le TLB et d’autres complexités supplémentaires pour exploiter les bits de protection, ce qui réduit un peu la simplicité

  • Lors de ma dernière tentative de Hackintosh, j’ai fait quelque chose de similaire en utilisant Linux comme bootloader et hyperviseur minimal, et cela fonctionnait plutôt bien. L’inconvénient, c’est que sans vrais événements GPU, on reste bloqué sur la résolution et les réglages décidés par Linux, avec moins de liberté. Si cet OS pouvait fonctionner non pas comme un vrai OS mais comme un exécutable UEFI, alors les pilotes vidéo UEFI pourraient peut-être suffire pour le graphisme, mais je ne sais pas vraiment si c’est faisable tout en gardant des fonctionnalités dignes d’un OS

• Plus encore que le fait que la boucle de répétition ne doive pas monopoliser le CPU trop longtemps et que les tâches longues doivent impérativement faire un yield explicite, je pense que le plus gros inconvénient est que plus on ouvre d’applis, plus chacune ralentit. Je n’ai presque jamais lancé plus de dix applis, mais en me basant sur mon expérience avec jusqu’à 30 onglets ouverts, si chacun était un processus, la baisse de performances serait très nette. Si le matériel est suffisamment rapide, ce n’est pas un problème, mais pour un traitement lourd comme le rendu vidéo, par exemple, passer de 1 seconde à 30 secondes se ressentirait fortement. Malgré cela, le simple fait d’avoir implémenté tout l’OS de cette manière est extrêmement malin, impressionnant et enthousiasmant

  • Tant que les applis terminent leur travail à temps, il n’y a aucune raison qu’elles ralentissent. Elles s’exécutent, terminent, puis attendent la frame suivante. Si les ressources manquent au point que le temps d’attente tombe à zéro ou en dessous, alors l’ensemble ralentit, mais c’est tout de même moins élégant qu’un scheduler équitable complexe. Chaque programme fait un yield explicite quand sa frame est prête, donc les applis qui n’ont rien à faire ne consomment presque pas de temps

• Au-delà du scheduling coopératif, la défense contre les attaques Spectre semble difficile, et je me demande si l’efficacité sera au rendez-vous sans mémoire virtuelle. Par exemple, lors du traitement de memory.grow en WASM, si la mémoire d’une autre appli se trouve sur le chemin, il pourrait devenir nécessaire de faire un memmove de l’ensemble ; je me demande si c’est réellement faisable. Cela dit, c’est un projet vraiment impressionnant

  • Si Spectre est bien un vecteur d’attaque, quel est exactement le modèle de menace supposé ? Dans l’architecture actuelle, toutes les applis sont directement compilées dans le kernel et le navigateur web n’exécute pas non plus de JavaScript, donc il semble qu’il n’existe pas vraiment de voie d’entrée pour du code non fiable
  • J’aimerais une explication plus détaillée

• Je me demande comment ce genre d’initiative évoluera quand les composants wasm deviendront réalité. J’apprécie beaucoup la conception unikernel, et le fait que Munal OS offre déjà des fonctionnalités variées est impressionnant. J’espère voir wasm utilisé non seulement pour une seule grosse appli, mais aussi pour héberger une multitude de petits processus et de sous-environnements. Avec wasi preview3, la coexistence du synchrone et de l’asynchrone devrait bientôt s’ouvrir, et à ce moment-là wasm disposera de tous les éléments d’un runtime généraliste. Je trouve toujours dommage que le bridging d’objets hôtes reste centré sur JS, mais j’aimerais voir la promesse des composants wasm — standardisation, légèreté, sandboxing, composition entre langages — se concrétiser dans le monde réel comme une véritable capacité d’exécution, et pas seulement comme un format de distribution. Voir aussi cette présentation : What is a Component (and Why)

  • Quand tu parles de ce sujet, tu voulais peut-être mentionner cette vidéo : lien YouTube ?
  • J’ai commencé à créer une appli Rust qui prend en charge SDL3 et embarque V8 pour permettre le scripting : présentation sur le blog. Mais ce à quoi je réfléchis sérieusement, c’est à forker cela pour y embarquer wasmtime ou wasmi afin de permettre le scripting dans n’importe quel langage. On pourrait même embarquer les compilateurs pour qu’il suffise de donner un fichier à l’appli pour qu’il soit scripté directement. C’est parce que wasmtime et wasmi sont plus rapides que d’autres moteurs de script : données comparatives. Le point gênant, c’est qu’il faut configurer tout l’environnement de code, donc l’avantage d’entrée d’un script est plus faible. Malgré tout, l’idée est tellement cool que j’ai envie d’essayer au moins une fois

• Dans la conférence PyCon 2014 « The Birth and Death of Javascript », j’ai vu un passage qui présentait l’avenir sous la forme d’un sandbox d’OS implémenté en asm.js (l’ancêtre de wasm), et l’idée m’a semblé proche du cœur de la conception de ce projet ; je me demande si cela a eu une influence : lien vers la conférence

  • Je pense qu’il est plus probable que l’influence vienne plutôt de Midori, l’OS de recherche de Microsoft : présentation de Midori

• Je suis surpris de voir que cet OS intègre même son propre navigateur web : source du navigateur web. On peut aussi voir dans la vidéo de démonstration qu’il affiche Hacker News

  • Avant que les navigateurs web ne débordent de fonctionnalités comme JS, CSS et autres, un petit navigateur comme celui-ci pouvait afficher le web avec très peu de dépendances. Aujourd’hui, c’est plutôt frustrant de constater qu’on ne peut plus consulter de manière vraiment utile la majeure partie du web. Je pense qu’il faudrait séparer plus clairement le web de contenu et le web applicatif. Le web de contenu n’a besoin que d’un client HTTP très simple et d’un parseur HTML, tandis que les web apps, comme cet OS, pourraient très bien reposer sur wasm avec seulement quelques API matérielles. En revanche, il faut impérativement la prise en charge d’UDP

• Je trouve cela étonnant, et je me demande si ce type d’architecture pourrait représenter l’avenir des OS. Le readme lui-même est très intéressant. Je me demande aussi pourquoi wasmi a été choisi au lieu de wasmtime. J’aimerais essayer cet OS moi-même dans une VM, et j’ai aussi envie de porter ma bibliothèque GUI sur Munal

  • Je partage l’expérience selon laquelle construire wasmtime en mode no_std est tellement compliqué que j’ai fini par choisir wasmi
  • J’ajoute une blague sur SPECTRE et MELTDOWN qui s’invitent dans toute discussion sur l’avenir de l’architecture des OS modernes
  • Puisqu’on parle d’isolation des applis par virtualisation, on vit déjà un futur similaire avec Qubes OS. Là-bas, l’isolation des applis est extrêmement solide

• Depuis l’époque de Xerox PARC, les tentatives de « transformer l’espace utilisateur en bytecode » reviennent régulièrement, et à mes yeux les seuls vrais succès commerciaux ont été IBM i, ChromeOS et Android. Cela dit, ce projet est très cool et j’espère qu’il réussira

  • À chaque fil sur WebAssembly, on a désormais l’impression que la même vieille histoire des VM à bytecode revient de façon quasi rituelle. C’est toujours la même évaluation répétée sur le même ton, alors que dans les communautés de développeurs, il est inévitable de voir apparaître diverses expérimentations et approches nouvelles. J’aimerais entendre des avis plus précis, au-delà de ce simple réflexe de reconnaissance de motifs
  • Comme ce concept présente des avantages tellement évidents, de nouvelles tentatives vont inévitablement continuer jusqu’à ce qu’il s’impose vraiment comme standard. wasm est clairement orienté vers cet objectif, ce qui le distingue nettement de la JVM et d’autres approches
  • ChromeOS n’est qu’un navigateur qui utilise V8 un peu par hasard, et Android aurait réussi avec n’importe quoi. Le succès de ces deux OS tient au prix, pas à la technologie

• La conception même d’un OS client est surprenante. Je pense qu’une telle architecture pourrait aussi avoir une utilité immédiate côté serveur. En réduisant le kernel au strict minimum et en ne gardant qu’une seule appli en fonctionnement, on peut diminuer les frontières de sécurité inutiles. Par exemple, un key/value store conviendrait bien à ce type de structure. Je me demande si ce modèle d’I/O permet de bonnes performances réseau, et s’il existe des techniques particulières pour réduire les copies mémoire inutiles lors de l’hébergement de WASM