Munal OS - WASMサンドボックス化を採用したグラフィックスベースの実験用オペレーティングシステム

• Rustで完全に実装されており、unikernel設計とWASMベースのサンドボックス型セキュリティモデルを採用したグラフィックスベースの実験用オペレーティングシステム
• EFIバイナリにカーネル、WASMエンジン、すべてのアプリが内蔵され、最小化された構造と独自のシステムコールインターフェースを提供
• VirtIOベースのドライバによりQEMU上で動作し、入力・ネットワーク・GPU管理が割り込みなしのポーリング方式で実装
• グローバルイベントループと協調スケジューリングにより、単純化された動作構造とアプリケーションごとのリソース監視機能をサポート
• 独自のUIツールキット Uitkと内蔵アプリ（ウェブブラウザ、テキストエディタ、Pythonターミナル）を提供し、多様な言語でWASMアプリを開発可能

---

Munal OSとは

• Munal OSはRustで完全に開発された実験用オペレーティングシステムで、unikernelベースのアーキテクチャとWASMサンドボックス化を組み合わせ、新しいOS設計を探るために作られたプロジェクト
• 複雑さを減らして必要な要素だけを適用し、現代的なツールで簡素化されたシステム構造の実現を目指している

主な特徴

• フルグラフィック環境およびHD解像度をサポートし、マウスとキーボードのインターフェースを搭載
• サンドボックス方式のアプリ実行により、ユーザーアプリケーションのカーネルメモリへのアクセスを遮断
• ネットワークドライバと独自のTCPスタックを内蔵
• カスタマイズ可能なUIツールキット（Uitk）を含み、多様なウィジェット、柔軟なレイアウト、テキストレンダリングをサポート
• 標準搭載アプリ: ウェブブラウザ（DNS、HTTPS、基本的なHTMLをサポート）、テキストエディタ、Pythonターミナル

アーキテクチャ

• EFIバイナリベースの構造

  • ブートローダーなしでEFIバイナリ形式として起動し、カーネル/WASMエンジン/アプリが1つのファイルに内蔵される
  • UEFIブートサービスは最短時間で終了し、システムクロック以外には追加利用しない

• アドレス空間管理

  • 仮想アドレス空間を使用せず、UEFIが残したidentity-mappedアドレスをそのまま使用
  • ページテーブルの変更なし。カーネルメモリの直接保護はWASMサンドボックス化で補完

• ドライバとハードウェアサポート

  • PS/2やVGAの代わりに、VirtIO 1.1仕様を利用するPCIドライバを直接実装
    • キーボード、マウス、ネットワーク、GPU向けドライバを提供
  • 割り込みは不使用で、すべてのドライバはポーリング方式で設計
  • QEMU以外の実機ハードウェアでの実行は未対応で、今後の追加開発が必要

• イベントループとスケジューリング

  • マルチコア/割り込みは未対応で、全体の動作は単一のグローバルイベントループ上で線形に実行
    • 各ループごとにネットワーク/入力ドライバのポーリング、デスクトップUIとアプリの実行、GPUフレームバッファの更新を行う
  • 性能解析が容易で、各ループサイクルごとの時間測定が可能
  • アプリは自らCPU占有を解放する必要があり、長時間の処理では明示的な譲歩が必要
  • 協調スケジューリングベースだが、Wasmiエンジンのfuel limit機能による不正動作アプリの強制終了も可能（未実装）

アプリケーション実行構造

• [Wasmi WASMエンジン]を内蔵し、アプリ実行時に完全なサンドボックス化とカーネル分離を提供
• カーネルレベルでシステムコールAPIを提供し、アプリからマウス/キーイベントの取得、TCPソケット利用、フレームバッファ出力などが可能
• アプリのレンダリング結果はOSがデスクトップ上に合成して出力
• Rust以外の言語でもアプリ作成が可能で、WASMビルドに対応していれば利用制限はない
• WASI互換性は部分対応。完全準拠ではなく、主要な外部依存関係の活用に必要な最小実装のみを含む
• アプリごとの**専用ログストリーム（stdout類似）**があり、デスクトップの「監査」ビューでリソース使用量とともに確認できる

UIツールキット（uitk）

• Munal OSとWASMアプリの両方で使用される独自の即時モードUIキット
• 基本ウィジェット（ボタン、プログレスバー、テキスト編集、スクロールキャンバス）および三角形ラスタライザを提供
• グローバルスタイルシートベースの統一スタイリングと、個別要素ごとのオーバーライドをサポート
• 効率的なキャッシュシステムにより不要な再レンダリングを防止
  • 各領域を「タイル」に区分し、Rustのミュータビリティ規則に基づく変更検知アルゴリズムを使用

ビルドおよび実行環境

• Rust Nightly 2025-06-01およびQEMU 10.0.0以上でビルド・実行可能

主な参考資料とクレジット

• Philipp OppermannのRust OSチュートリアルおよびOSDev Wiki文書
• Wasmi、smoltcp、Rustls、RustPythonなどの主要オープンソースを活用
• さまざまなオープンソースフォント、アイコン、壁紙素材を使用

Munal OSの意義と利点

• 単一のEFIバイナリ構造と革新的なサンドボックス化の組み合わせにより、従来のOS設計パラダイムを再考
• QEMU環境に最適化された独特なポーリングベースのドライバ構造により、実システムのハードウェア依存性を最小化
• システムリソース管理の透明性と、単純な構造から得られる学習・実験上の価値が大きい
• 言語や環境の制約なくWASMアプリのエコシステムを拡張できる可能性が大きい

[GN⁺]

Hacker Newsの意見

• 各反復でネットワークと入力ドライバをポーリングし、デスクトップインターフェースを描画し、各アクティブなWASMアプリケーションを1ステップ実行した後、GPUフレームバッファをフラッシュする構造になっている点が興味深い。この機能をWasmiでどのように実装したのか気になってコードを見に行った GitHubコードへのリンク。最新のWasmi(v0.45+)では、fuelが不足したときにyieldできるよう、resume可能な関数呼び出し機能が拡張されていることを伝えたい Wasmiドキュメントへのリンク。すでにfuel meteringを使っているので、実行ステップではより効率的な方法になるかもしれない。利用例は Wasmi Wastランナーの例 で確認できる

  • 改めてWasmiを作ってくれてありがとう。Wasmiにfuelが尽きたときにyieldできる機能があるという話は本当に興味深い。以前のドキュメントではこういう機能を見つけられず残念だったが、もしあったと分かっていたらWASMアプリの設計方針は違っていたと思う
  • OPではないが、この機能がなぜ役立つのかよく分からない。関数でコルーチンを作って開始し、もし実行中にメモリ不足で失敗したら追加メモリを与えてそのコルーチンを再びresumeできる、という意味なのか。もしそうなら従来の動作と何が違うのか気になる。WASMにはtry/catchがないのかとも思う。失敗した状態でmallocを明示的に再試行しなければならないなら、そこまでして得られる違いがはっきりせず混乱する
  • WasmiがGUIアプリを動かせるほど十分に速いという点に興奮した。自分は移植性と可搬性の高いGUIアプリを作るためのアプリランタイムを開発中だ。パフォーマンスと実装の簡潔さのバランスを取るためにwasmを選んでおり、実質的に数人、あるいは一人のチームだけでランタイムをさっと構築できることを期待している。Wasmiのような最適化されたインタプリタベースのwasmランタイムがGUIアプリも無理なく動かせるという事実に、大きな可能性を感じる

• VirtIOに依存する構造なので、Munal OSはまだ実機では動かないという点に触れつつ、もし実機で動かすなら、直接ドライバを追加する代わりにLinuxをブートローダとして使い、ミニマルなハイパーバイザ上でOSを動かす戦略も面白いアプローチだと思う。こうすれば「VirtIOがプラットフォーム」というコンセプトを維持できる。アプリ実行にはWASM、プラットフォームにはVirtIOを採るという構成でアイデンティティを保っているのが良い。ただしセキュリティの観点ではMMUの利用が必要だ。設計上、仮想メモリまで導入しなくてもよいとしても、保護ビットを使うためにページテーブルやTLBの管理など追加の複雑さが生じ、シンプルさはやや損なわれる

  • 最後にHackintoshを試したとき、Linuxをブートローダ兼ミニマルハイパーバイザとして使って似たような運用をしてみたが、効果は悪くなかった。欠点は、実際のGPUイベントなしにLinuxが決めた解像度と設定に固定されるため自由度が制限されることだ。もしこのOSが本物のOSではなくUEFI実行ファイルとして動けるなら、UEFIビデオドライバだけでもグラフィックス処理は可能かもしれないが、実際にOSらしい機能を持たせたままそれが試せるのかは分からない

• 反復ループが長時間CPUを占有してはいけないことや、長い処理は必ず明示的にyieldしなければならないこと以上に大きな欠点は、アプリを多く開くほど各アプリの処理速度が遅くなることだと思う。自分で10個以上アプリを開いたことはほとんどないが、タブを30個まで開いた経験からすると、それぞれがプロセスなら性能低下はかなりはっきり表れるはずだ。ハードウェアが十分に速ければ問題ないだろうが、例えば動画レンダリングのような重い処理では1秒が30秒になるような大きな差を体感するかもしれない。それでも、OS全体をこのように実装したという事実そのものが非常に賢く、本当にすごくてわくわくする試みだ

  • アプリがやるべきことを時間内に終えられる限り、必ずしも遅くなる必要はない。実行して終え、次のフレームを待つだけだ。リソースが足りず待ち時間が0以下になれば全体が遅くなるが、それは複雑で公平なスケジューラよりも洗練されていない方式だということ。各プログラムは自分のフレーム準備が終わったら明示的にyieldする構造なので、やることのないアプリはほとんど時間を使わない

• 協調的スケジューリングに加えて、Spectre攻撃への防御も難しそうだし、仮想メモリなしで効率が出るのかも疑問だ。例えばWASMでmemory.growを処理するとき、他のアプリのメモリが引っかかっていたら全体をmemmoveしなければならない状況が起きるかもしれず、それが本当に実用的なのか気になる。それでも非常に印象的なプロジェクトだ

  • Spectreが攻撃ベクトルになるなら、具体的にどんな脅威モデルを前提にしているのか知りたい。現在の構造では、すべてのアプリがカーネルに直接コンパイルされていて、WebブラウザもJavaScriptを実行しないため、信頼できないコードが入り込む経路自体がないように見える
  • 詳しい説明をお願いしたい

• wasmコンポーネントが実現したとき、この種の試みがどう変わるのか気になる。unikernelの設計は高く評価しているし、Munal OSが多様な機能を持っている点も印象的だ。wasmが単一の巨大アプリ向けだけでなく、多数の小さなプロセスやサブ環境をホストする用途にも使われてほしい。wasi preview3では同期と非同期の共存がまもなく可能になり、そうなればwasmは汎用ランタイムの要素をほぼすべて備えることになる。それでも、ホストオブジェクトのブリッジが依然としてJS偏重なのは残念だが、wasmコンポーネントの約束しているもの（標準、軽量、サンドボックス、言語間の組み合わせ）が、単なる配布フォーマットではなくランタイム能力として現実に示されてほしい。以下のトークも参考になる What is a Component (and Why)

  • この話題をするとき、もしかしてこの動画 YouTubeリンク に言及しようとしていたのでは？
  • 自分はSDL3をサポートし、V8を内蔵してスクリプティング可能なRustアプリを作り始めた ブログ紹介。ただ本気で考えているのは、これをforkしてwasmtimeやwasmiを埋め込み、どんな言語でもスクリプティングできるようにすることだ。コンパイラも一緒に内蔵して、ファイルを渡すだけですぐスクリプトが動く構造にできるかもしれない。wasmtimeとwasmiは他のスクリプティングエンジンより高速だからだ 比較データ。ただ不便なのは、コード環境を全部セットアップしなければならず、スクリプトとしての導入のしやすさが弱いことだ。それでもアイデア自体があまりに魅力的なので、一度はやってみたい

• 「The Birth and Death of Javascript」というPycon 2014のトークで、asm.js（現在のwasmの前身）でOSサンドボックスを実装する未来が紹介されていたのを見たが、このアイデアはこのプロジェクトの設計の核心と似ているように思えるので、影響を受けているのか気になる トークへのリンク

  • むしろMicrosoftの研究用OSであるMidoriのほうから影響を受けている可能性が高いと思う Midori紹介

• このOSには独自のWebブラウザまで内蔵されていて驚いた Webブラウザのソース。デモ動画ではHacker Newsをレンダリングしている様子も確認できる

  • WebブラウザにJSやCSSなどの機能があふれ込む前は、こうした小さなブラウザでも最小限の依存関係でWebを見ることができたが、今ではむしろ大半のWebを意味のある形では見られないのが残念だ。コンテンツ中心のWebとアプリ中心のWebを、もっと明確に分ける必要があると思う。コンテンツWebには非常に単純なHTTPクライアントとHTMLパーサだけで足り、WebアプリはこのOSに似た形でwasmベース＋少数のハードウェアAPIだけあれば十分だ。ただしUDPのサポートは必須だ

• 驚くべきだし、こうした構造がOSの未来になり得るのか気になる。readme自体もかなり面白い。wasmiではなくwasmtimeを選ばなかった理由も知りたい。自分もVMでこのOSを直接触ってみたいし、自分のGUIライブラリをMunalへ移植してみたい気持ちもある

  • wasmtimeをno_stdモードでビルドするのがあまりにも大変で、結局wasmiを選んだという経験を共有する
  • 最新のOS構造の未来の話にSPECTREとMELTDOWNが割り込んでくる、という冗談を加える
  • アプリ隔離を仮想化で行うという点では、Qubes OSでもすでに似た未来を体験していると述べる。あちらではアプリ隔離が非常に強固に行われている

• Xerox PARCの時代から「ユーザースペースをバイトコード化しようとする試み」は繰り返されてきており、実際に市場で成功した例はIBM i、ChromeOS、Androidくらいだと思う。ただ、このプロジェクトは素晴らしいし、うまくいってほしい

  • WebAssembly関連のスレッドのたびに、古いバイトコードVMの話を持ち出すのが、もはやパターンになっているように見える。毎回ほぼ同じ論調で繰り返し評価しているが、開発者コミュニティでは多様な試行錯誤や新しいアプローチが必然的に出てくるものだ。その基本的なパターン認識だけでなく、もっと踏み込んだ意見を聞きたい
  • この概念は利点があまりにも明確なので、標準としてしっかり定着するまで新しい試みが何度も繰り返されるのは避けられない。wasmは実際にそれを目指している点で、JVMなどとはかなり違う
  • ChromeOSは単にブラウザだからたまたまV8を使っているだけで、Androidは何を使っていても成功していたと思う。両OSが成功した要因は技術ではなく価格だ

• クライアントOSとしての設計自体が驚きだ。こうした構造はサーバーでもすぐに実用性がありそうに思える。カーネルを極小にして、動作する単一のアプリだけを残せば、不必要なセキュリティ境界を減らせるはずだ。例えばkey/value storeはこうした構造に向いているだろう。気になるのは、このIOモデルでネットワーク性能が十分に出るのか、そしてWASMホスティング時に不要なメモリコピーを減らすための特別な手法が適用できるのか、という点だ