WASMランタイムによるサンドボックス化

プロセス隔離の代わりに何を使うか

コンテナは namespace・cgroup・capability・seccomp を組み合わせて隔離しますが、隔離の単位は依然として「OSプロセス」であり、ホストカーネルを共有します。マイクロVMはハードウェア仮想化で壁を引き直しますが、ゲストカーネルの起動コストが乗ります。WASM（WebAssembly）ランタイムは第三の道です。プロセスでもVMでもなく、言語非依存のバイトコードVMを隔離境界にする発想で、起動速度と隔離強度を同時に狙います。

スタックマシンと静的検証がつくる壁

WASMモジュールはロード時にランタイムが単一パスで検証します。命令列がスタック上でどの型をやり取りするか（i32/i64/f32/f64 など）をすべての分岐で追跡し、型不整合や、存在しない関数・ローカル変数・グローバル変数のインデックス参照、構造化されていない制御フローがあれば実行前に拒否します。この検証はCのunsafeなポインタ演算のような「実行してみないと壊れるか分からない」コードを実行前に排除する点が、ネイティブコードのサンドボックスとの決定的な違いです。

隔離の核はメモリモデルにあります。WASMの各インスタンスは線形メモリと呼ぶ1枚の連続バイト配列だけを持ち、ロードやストア命令はすべてこの配列内のオフセットとして解決されます。実装は境界チェック付きの配列アクセス、またはガードページを敷いた仮想アドレス予約のどちらかでこれを実現し、いずれの方式でもモジュールのコードが線形メモリの外を指すポインタを組み立てる手段を持ちません。加えて関数呼び出しはモジュール内の固定インデックスを指す直接呼び出し（call）か、テーブルと型シグネチャの一致を実行時にチェックする間接呼び出し（call_indirect）のいずれかに限られ、任意の生アドレスへ飛ぶ形では届きません。

この構造の帰結として、WASMモジュールはデフォルトでは何もできません。ファイルを開く命令もソケットを張る命令も、命令セットに存在しないからです。外界とやり取りする唯一の経路は、ホストが明示的に注入した「インポート関数」の呼び出しに限られます。ここに capability ベースのセキュリティモデルの土台があります。

WASI：暗黙の名前空間を廃したシステムインターフェース

言語ランタイムがファイルやネットワークを使うには、POSIXに相当する標準インターフェースが要ります。これを定義するのが WASI（WebAssembly System Interface）です。WASIの設計はPOSIXと似た関数群（path_open・fd_read・fd_write 等）を持ちながら、アクセス制御の哲学が根本的に異なります。

具体的には、モジュールは/etc/passwdのような絶対パス文字列を渡しても、それを解決する術がありません。WASIのpath_openは既に開かれたディレクトリハンドル（capability）を起点にした相対パス解決しか許さず、ホストが起動時にどのディレクトリハンドルも渡さなければ、モジュールはファイルシステムに触れる方法を持ちません。これは「実行時にパスを検査して拒否する」のではなく、そもそも到達する経路が存在しないという強さの違いです。ネットワークやクロックも同様に、ホストが明示的に許可したソケットや権限だけがモジュールに見えます。

起動速度の内訳とコンテナ・unikernelとの比較

WASMランタイムが「軽い」のは偶然ではなく、削れる層が構造的に少ないためです。

コンテナは軽量とはいえ、rootfsのマウントや複数の namespace 生成といったカーネル側のセットアップコストを起動のたびに払います。マイクロVMはさらにゲストカーネルのブート自体が必要です。WASMランタイムは新しいOSプロセスもゲストカーネルも起動せず、既に動いているホストプロセスの中でモジュールをロードして即座に実行に移れるため、コールドスタートが1桁から2桁短くなります。unikernelはアプリとOS機能を単一アドレス空間に静的リンクして起動を縮める点でWASMと発想が近い一方、unikernelは依然としてハードウェア（ないし仮想ハードウェア）上でブートするイメージであるのに対し、WASMモジュールはホストプロセスに動的にロードされるデータに近く、ブートという概念自体を持ちません。

何を失っているか

この軽さは無償ではありません。第一に、**隔離の壁がハードウェアではなくソフトウェア（ランタイム実装）**にある点です。マイクロVMのゲスト/ホスト境界はCPUの仮想化支援機能が引くのに対し、WASMの境界はランタイムの検証器とインタプリタ／JITコンパイラのコードが正しく実装されている前提に依存します。検証器やJITにバグがあれば、線形メモリ外への書き込みという形で境界を破られる可能性があり、実際に主要ランタイムでも境界チェック省略に類する脆弱性が報告されてきました。第二に、WASI自体はプロセス並行性・シグナル・高精度なリアルタイムI/O多重化など、POSIXが提供してきた機能の一部を意図的にまだ十分にカバーしていません。第三に、数値演算中心ではないワークロード（重いシステムコール往復や特殊なハードウェアアクセス）では、capabilityの受け渡しやホスト関数呼び出しの層がオーバーヘッドになります。