マイクロVM（Firecracker・gVisor）の隔離設計

なぜコンテナの隔離では足りないのか

コンテナは namespace・cgroup・capability・seccomp を組み合わせた軽量な隔離ですが、決定的な弱点があります。すべてのコンテナがホストのカーネルを共有する点です。コンテナ内のプロセスが発行するシステムコールは、最終的にホストの単一のカーネルが処理します。つまりカーネルに脆弱性があれば、namespace で見える範囲を区切っていても、そのバグを突いて隔離の壁を越えられます。

問題の本質は攻撃面（attack surface）の広さです。Linux のシステムコールは 350 を超え、各々が複雑なカーネルコードに繋がります。seccomp で呼べる呼び出しを絞っても、許可した数十個の窓口の奥はやはり巨大な共有カーネルです。マルチテナント環境（他人のコードを同じホストで走らせるサーバーレスや CI など）では、この共有カーネルが許容しがたいリスクになります。マイクロVM／サンドボックスは、この「共有カーネルへの直接到達」を別の隔離機構で置き換える技術です。

Firecracker：デバイスを削ぎ落とした最小VMM

Firecracker は AWS Lambda／Fargate を支える VMM（Virtual Machine Monitor）で、KVM の上に乗ります。KVM が CPU／メモリ仮想化（VM entry/exit、EPT/NPT による二段アドレス変換）を担う点は QEMU と同じですが、Firecracker は QEMU を置き換える、極端に小さい VMM です。

設計の核はデバイスモデルの最小化です。汎用 VMM の QEMU が PCI バス・多種のNIC・USB・VGA など膨大なデバイスをエミュレートするのに対し、Firecracker はvirtio準拠の最小限だけを持ちます。

この削減が効くのは二重の意味です。第一に起動の速さとメモリ密度。PCI 列挙も BIOS も省き、カーネルを直接ロードして起動するため、1ホストに数千のマイクロVMを詰められます。第二にVMM自体の攻撃面。ゲストがVMから抜け出す（VM escape）には、まず VMM のデバイスエミュレーションコードのバグを突く必要があります。デバイスが数個しかなく実装が Rust で小さければ、その的が小さくなります。さらに Firecracker 自身を seccomp プロファイルと jailer（namespace・cgroup・chroot で包む補助プロセス）で囲い、**「VMを抜けても、次はホストOS側の最小化された牢に落ちる」**という多層防御を組みます。

gVisor：ユーザー空間に書いたカーネル

gVisor（Google製、runsc ランタイム）は逆の発想です。VMを使わず、それでも共有カーネルへの直接到達を断ちます。中核は Sentry と呼ぶ、Go で書かれたユーザー空間のカーネルです。

仕組みはこうです。サンドボックス内のアプリがシステムコールを発行すると、それはホストカーネルへ素通りせず、Sentry が横取りします。Sentry はそのシステムコール（open・read・mmap・futex など 200 以上）を自前で再実装しており、アプリから見える「カーネル」として振る舞います。ファイルアクセスは Gofer という別プロセスへ委譲し、ネットワークも独自スタックで処理します。アプリのシステムコールがホストカーネルに直接届くことは、原則ありません。

[従来のコンテナ]
  アプリ ──syscall──► ホストカーネル（共有・巨大な攻撃面）

[gVisor]
  アプリ ──syscall──► Sentry（ユーザー空間カーネル, Go）
                         │ ごく一部のhostcallだけ
                         ▼
                      ホストカーネル（seccompで強く制限）

肝は、Sentry 自身がホストカーネルに対して呼べるシステムコールを seccomp で極端に絞っていることです。アプリが何百種を呼ぼうとも、ホストカーネルが実際に晒されるのは Sentry が使う数十種の安全な呼び出しだけ。攻撃者はまず Sentry（Go製でメモリ安全寄り）を破り、さらにその先の絞られた窓口を抜けねばならず、二段の壁になります。

攻撃面とオーバーヘッドのトレードオフ

両者は「コンテナの弱い隔離を補う」目的を共有しつつ、削る相手とコストが異なります。

Firecracker のコストは、本物のゲストカーネルを各VMで動かす点にあります。隔離は強固で互換性も高い反面、ゲストカーネル分のメモリと、I/Oが必ず virtio→VMM を経る間接コストを払います。gVisor のコストは、システムコールがすべて Sentry を経由する点にあります。CPU 計算中心のワークロードでは差は小さい一方、システムコールやI/Oが多発するワークロード（DBや大量のファイル操作）では、横取りと再実装の往復がオーバーヘッドとして効きます。また Sentry が未実装の呼び出しを使うアプリは動かないか縮退するため、互換性は Firecracker に劣ります。

まとめ

• コンテナは namespace/cgroup で区切ってもホストカーネルを共有するため、共有カーネルが攻撃面になる。マイクロVM／サンドボックスはこの境界を置き換える。
• Firecracker は KVM 上の最小 VMM。デバイスを virtio など数個に削り、PCI/BIOS も省いて起動を約125ms・常駐を数MBに抑える。隔離はハードウェア仮想化が引く。
• gVisor は VM を使わず、システムコールを Sentry（Go製のユーザー空間カーネル）で横取り再実装し、ホストカーネルへの直接到達を seccomp で強く絞る。捕捉は KVM 方式が速い。
• トレードオフは攻撃面とオーバーヘッド。Firecracker は強い隔離と高互換だがゲストカーネル分のコスト、gVisor はより軽いが syscall/I/O 多発で遅く互換に穴が出る。いずれも多層防御が前提。