Munal OS - sistema operativo experimental gráfico con sandboxing WASM

• Sistema operativo experimental gráfico implementado completamente en Rust, que usa un diseño unikernel y un modelo de seguridad con sandboxing basado en WASM
• El kernel, el motor WASM y todas las apps están integrados en un binario EFI, lo que ofrece una estructura minimizada y una interfaz de llamadas al sistema distintiva
• Funciona en QEMU mediante drivers basados en VirtIO, y la gestión de entrada, red y GPU está implementada con sondeo en lugar de interrupciones
• Mediante un bucle global de eventos y planificación cooperativa, soporta una estructura de operación simplificada y monitoreo de recursos por aplicación
• Incluye su propio toolkit de UI Uitk y apps integradas (navegador web, editor de texto, terminal de Python), con posibilidad de desarrollar apps WASM en varios lenguajes

---

Qué es Munal OS

• Munal OS es un sistema operativo experimental desarrollado completamente en Rust, creado para explorar nuevos diseños de SO combinando una arquitectura basada en unikernel con sandboxing WASM
• Busca reducir la complejidad y aplicar solo los elementos esenciales para lograr una estructura de sistema simplificada con herramientas modernas

Características principales

• Soporte para entorno gráfico completo y resolución HD, con interfaz de mouse y teclado
• Ejecución de apps en sandbox, bloqueando el acceso de las aplicaciones de usuario a la memoria del kernel
• Driver de red y pila TCP propia integrados
• Incluye un toolkit de UI personalizable (Uitk), con varios widgets, layout flexible y renderizado de texto
• Apps incluidas por defecto: navegador web (soporte para DNS, HTTPS y HTML básico), editor de texto y terminal de Python

Arquitectura

• Estructura basada en binario EFI

  • Se ejecuta en formato de binario EFI sin bootloader, con el kernel, el motor WASM y las apps integrados en un solo archivo
  • Los servicios de arranque de UEFI se cierran lo antes posible y no se aprovechan para nada adicional salvo el reloj del sistema

• Gestión del espacio de direcciones

  • No usa espacio de direcciones virtual, sino que utiliza directamente las direcciones identity-mapped que dejó UEFI
  • No hay cambios en las tablas de páginas. La protección directa de la memoria del kernel se complementa con sandboxing WASM

• Drivers y soporte de hardware

  • En lugar de PS/2 o VGA, implementa directamente drivers PCI que aprovechan la especificación VirtIO 1.1
    • Incluye drivers para teclado, mouse, red y GPU
  • No usa interrupciones; todos los drivers están diseñados con sondeo
  • No soporta ejecución en hardware físico fuera de QEMU; se requiere desarrollo adicional a futuro

• Bucle de eventos y planificación

  • No soporta multicore ni interrupciones; toda la operación se ejecuta linealmente en un único bucle global de eventos
    • En cada iteración del bucle se hace sondeo de los drivers de red/entrada, se ejecutan la UI del escritorio y las apps, y se actualiza el framebuffer de la GPU
  • Facilita el análisis de rendimiento, ya que se puede medir el tiempo de cada ciclo del bucle
  • Las apps deben liberar explícitamente el uso del CPU; las tareas largas deben ceder el control de forma explícita
  • Está basado en planificación cooperativa, pero podría soportar la finalización forzada de apps defectuosas mediante la función de fuel limit del motor Wasmi (aún no implementado)

Estructura de ejecución de aplicaciones

• Incluye el [motor WASM Wasmi], que al ejecutar apps ofrece sandboxing completo y separación del kernel
• A nivel de kernel ofrece una API de llamadas al sistema, con la que las apps pueden consultar eventos de mouse/teclado, usar sockets TCP, escribir en el framebuffer, etc.
• El resultado de renderizado de las apps es compuesto por el SO y mostrado en el escritorio
• Es posible crear apps también en lenguajes distintos de Rust; no hay restricciones mientras soporten compilación a WASM
• La compatibilidad con WASI es parcial. No cumple completamente con el estándar y solo incluye la implementación mínima necesaria para aprovechar dependencias externas importantes
• Cada app tiene su flujo de logs dedicado (similar a stdout), visible junto al uso de recursos en la vista de “auditoría” del escritorio

Toolkit de UI (uitk)

• Es un kit de UI en modo inmediato propio, usado tanto por Munal OS como por las apps WASM
• Incluye widgets básicos (botones, barras de progreso, edición de texto, canvas con scroll) y un rasterizador de triángulos
• Usa una hoja de estilos global para un estilo unificado, con soporte para overrides por elemento
• Cuenta con un sistema de caché eficiente para evitar rerenderizados innecesarios
  • Divide cada área en “tiles” y usa un algoritmo de detección de cambios basado en las reglas de mutabilidad de Rust

Entorno de compilación y ejecución

• Puede compilarse y ejecutarse con Rust Nightly 2025-06-01 y QEMU 10.0.0 o superior

Referencias principales y créditos

• El tutorial de Rust OS de Philipp Oppermann y la documentación de OSDev Wiki
• Uso de proyectos open source importantes como Wasmi, smoltcp, Rustls y RustPython
• Uso de diversas fuentes, íconos y wallpapers de código abierto

Significado y ventajas de Munal OS

• Al combinar una estructura de binario EFI único con sandboxing innovador, replantea el paradigma tradicional de diseño de sistemas operativos
• Está optimizado para el entorno QEMU y su estructura distintiva de drivers basada en sondeo minimiza la dependencia del hardware de sistemas reales
• Ofrece transparencia en la gestión de recursos del sistema, y su estructura simple aporta un alto valor de aprendizaje y experimentación
• Tiene gran potencial para expandir el ecosistema de apps WASM sin restricciones de lenguaje o entorno

[GN⁺]

Comentarios en Hacker News

• Me pareció interesante que la estructura consista en hacer polling de la red y de los drivers de entrada en cada iteración, dibujar la interfaz de escritorio, ejecutar un paso de cada aplicación WASM activa y luego vaciar el framebuffer de la GPU. Busqué el código por curiosidad para ver cómo implementaron esto con Wasmi en GitHub. Quisiera comentar que en las versiones recientes de Wasmi (v0.45+) se amplió la funcionalidad de llamadas reanudables para que puedan hacer yield cuando se quedan sin fuel documentación de Wasmi. Como ya usa fuel metering, podría ser una forma más eficiente de manejar la etapa de ejecución. Se puede ver un ejemplo de uso en el ejemplo del runner Wast de Wasmi

  • Una vez más, gracias por crear Wasmi. La novedad de que Wasmi pueda hacer yield cuando se queda sin fuel me parece realmente interesante. En la documentación anterior no había encontrado algo así y, de haber existido, la dirección de diseño de las apps WASM habría sido distinta
  • No soy el OP, pero no termino de entender por qué esto ayudaría. ¿Significa que puedes convertir una función en corrutina, iniciarla y, si falla durante la ejecución por falta de memoria, darle más memoria y luego reanudar la corrutina? Si es así, me pregunto en qué se diferencia del comportamiento anterior. También pregunto si acaso no hay try/catch en WASM. Si de todos modos hay que reintentar explícitamente malloc después de fallar, me confunde cuál sería la diferencia práctica
  • Me emociona que Wasmi sea lo bastante rápido como para ejecutar apps GUI. Estoy desarrollando un runtime de aplicaciones para crear apps GUI portables y altamente transferibles. Elegí wasm por el equilibrio entre rendimiento y simplicidad de implementación, y espero que sea posible armar el runtime prácticamente con un equipo de una o pocas personas. El hecho de que un runtime de wasm basado en intérprete y tan optimizado como Wasmi pueda correr apps GUI sin problemas me hace ver muchísimo potencial

• Mencionan que, como depende de VirtIO, Munal OS todavía no funciona en hardware real, y me parece una estrategia interesante que, si quisieran operarlo en hardware real, en lugar de agregar drivers directamente usaran Linux como bootloader y ejecutaran el sistema operativo dentro de un hipervisor mínimo. De esa manera se podría mantener el concepto de que "VirtIO es la plataforma". La identidad de usar WASM para ejecutar apps y VirtIO para la plataforma me parece genial. Pero desde el punto de vista de seguridad sí haría falta usar una MMU. El diseño no necesariamente tendría que incorporar memoria virtual completa, pero usar bits de protección añadiría complejidad extra como tablas de páginas y manejo de TLB, lo que debilita un poco la simplicidad

  • En mi último intento de hackintosh hice algo parecido, usando Linux como bootloader y como hipervisor mínimo, y funcionó bastante bien. La desventaja es que, al no haber eventos reales de la GPU, todo queda fijo a la resolución y configuración que Linux haya decidido, así que hay menos libertad. Si este OS pudiera funcionar no como un OS real sino como un ejecutable UEFI, quizá sería posible manejar gráficos solo con el driver de video de UEFI, aunque no estoy seguro de si se puede intentar eso y seguir teniendo funciones propias de un OS

• Más que el hecho de que el bucle de iteración no deba ocupar la CPU por mucho tiempo y que los trabajos largos tengan que hacer yield explícitamente, creo que la desventaja mayor es que, cuantas más apps abras, más lento se vuelve el procesamiento de cada una. Casi nunca he tenido más de 10 apps abiertas a la vez, pero sí he llegado a tener 30 pestañas, y si cada una fuera un proceso la caída de rendimiento sería clarísima. Si el hardware es suficientemente rápido no habría problema, pero por ejemplo tareas pesadas como renderizar video podrían pasar de 1 segundo a 30 segundos, y la diferencia sería enorme. Aun así, implementar un OS entero de esta forma es en sí mismo una idea muy inteligente, impresionante y emocionante

  • Las apps no tendrían por qué volverse lentas mientras terminen lo que tienen que hacer a tiempo. Ejecutan, terminan y esperan al siguiente frame. Si faltan recursos y el tiempo de espera cae a 0 o menos, todo se vuelve más lento, aunque sigue siendo un enfoque menos elegante que un scheduler complejo y justo. Cada programa hace yield explícitamente cuando ya terminó de preparar su frame, así que las apps que no tienen nada que hacer casi no consumen tiempo

• Además del scheduling cooperativo, parece difícil defenderse de ataques Spectre, y también me pregunto si se puede lograr buena eficiencia sin memoria virtual. Por ejemplo, al manejar memory.grow en WASM, si se interpone la memoria de otra app, podría surgir una situación en la que haya que hacer memmove de todo; me pregunto si eso de verdad es viable. Aun así, es un proyecto realmente impresionante

  • Si Spectre es un vector de ataque, pregunto cuál sería exactamente el modelo de amenazas asumido. En la estructura actual, todas las apps se compilan directamente dentro del kernel y el navegador web tampoco ejecuta JavaScript, así que no parece haber una vía de entrada de código no confiable
  • Me gustaría una explicación más detallada

• Me pregunto cómo cambiarán este tipo de intentos cuando los componentes wasm se vuelvan realidad. Valoro mucho el diseño de unikernel, y también me impresiona que Munal OS tenga tantas funciones. Espero que wasm no se use solo para una sola app grande, sino también para alojar muchos procesos pequeños y subentornos. En wasi preview3 pronto se abrirá la posibilidad de convivencia entre sincronía y asincronía, y entonces wasm ya tendría todos los elementos de un runtime de propósito general. Sigue dándome pena que el bridging de objetos del host siga tan centrado en JS, pero quisiera que la promesa de los componentes wasm (estándar, ligereza, sandbox, composición entre lenguajes) se mostrara en la práctica como una capacidad real de runtime, y no como solo un formato de distribución. También comparto esta charla What is a Component (and Why)

  • Al hablar de este tema, ¿te referías quizá a este video en YouTube?
  • Empecé a hacer una app en Rust con soporte para SDL3 y V8 embebido para scripting presentación en el blog. Pero lo que estoy considerando seriamente es hacer un fork e incrustarle wasmtime o wasmi para permitir scripting en cualquier lenguaje. Incluso se podría incrustar también el compilador y hacer que baste con pasarle archivos para poder hacer scripting de inmediato. Eso sería porque wasmtime y wasmi son más rápidos que otros motores de scripting datos comparativos. El problema es que hay que preparar todo el entorno del código y eso le quita ventaja como punto de entrada para scripts. Aun así, la idea me parece tan buena que me gustaría intentarlo al menos una vez

• Vi la charla de Pycon 2014 “The Birth and Death of Javascript”, donde se presenta un futuro en el que asm.js (el precursor del wasm actual) implementa el sandbox de un OS, y me dio la impresión de que esa idea se parece mucho al núcleo del diseño de este proyecto; me pregunto si hubo influencia enlace a la charla

  • Más bien creo que es más probable que haya estado influido por Midori, el OS de investigación de Microsoft introducción a Midori

• Me sorprendió ver que este OS incluso trae su propio navegador web integrado código del navegador web. En el video de demostración también se puede ver que renderiza Hacker News

  • Antes de que a los navegadores web se les empezaran a acumular funciones como JS y CSS, navegadores pequeños como este podían mostrar la web con dependencias mínimas, pero ahora da pena que ya casi no puedan ver la mayor parte de la web de forma significativa. Creo que hace falta separar con más claridad la web de contenido y la web de aplicaciones. La web de contenido solo necesita un cliente HTTP muy simple y un parser de HTML, y las web apps, como en este OS, podrían bastarse con estar basadas en wasm y tener solo unas pocas APIs de hardware. Eso sí, sería indispensable tener soporte para UDP

• Además de parecerme sorprendente, me pregunto si una estructura así podría ser el futuro de los OS. Hasta el readme es bastante interesante. Me da curiosidad por qué eligieron wasmi en vez de wasmtime. Yo también quisiera probar este OS directamente en una VM y hasta me dan ganas de portar mi biblioteca GUI a Munal

  • Comparto la experiencia de que compilar wasmtime en modo no_std es demasiado complicado, y por eso terminé eligiendo wasmi
  • Agrego la broma de que, cuando se habla del futuro de la estructura de los OS modernos, también se cuelan SPECTRE y MELTDOWN
  • Menciono que, en cierto sentido, Qubes OS ya deja experimentar un futuro parecido, porque hace el aislamiento de apps mediante virtualización. Ahí el aislamiento entre apps sí queda muy bien asegurado

• Desde los tiempos de Xerox PARC se ha repetido constantemente la idea de “convertir el espacio de usuario en bytecode”, y creo que los únicos casos que realmente triunfaron en el mercado fueron IBM i, ChromeOS y Android. Aun así, este proyecto está genial y ojalá le vaya bien

  • Ya se siente como un patrón que esta persona repita siempre la misma historia sobre VMs antiguas de bytecode en cada hilo relacionado con WebAssembly. En cada ocasión hace prácticamente la misma evaluación con el mismo tono, pero en la comunidad de desarrollo es inevitable que aparezcan distintos intentos y nuevos enfoques a través de prueba y error. Más que un reconocimiento superficial de patrones, me gustaría escuchar una opinión más específica
  • Como este concepto tiene ventajas tan claras, es inevitable que sigan apareciendo nuevos intentos una y otra vez hasta que termine consolidándose bien como estándar. En eso wasm es claramente distinto de la JVM y otros, porque de verdad apunta a eso
  • ChromeOS es solo un navegador y usa V8 casi por accidente, y creo que Android habría triunfado usando cualquier otra cosa. El éxito de esos dos OS se debe al precio, no a la tecnología

• El diseño mismo del OS del lado cliente me parece sorprendente. Creo que una estructura así también tendría utilidad práctica inmediata en servidores. Si haces el kernel muy pequeño y dejas solo una app en ejecución, se podrían reducir fronteras de seguridad innecesarias. Por ejemplo, un key/value store sería ideal para una estructura así. Lo que me da curiosidad es si con este modelo de IO se consigue buen rendimiento de red, y si al alojar WASM se podrían aplicar técnicas especiales para reducir copias de memoria innecesarias