gVisorはユーザー空間カーネルでhost kernel syscall面を減らす
gVisorは、sandboxed applicationとhost Linux kernelの間にuserspaceで実装したapplication kernelを置く方式のsandboxである。
中心コンポーネントのSentryは、Linux system call interface、memory management、process model、signal、network stackなどをGoで再実装する。applicationが行ったsystem callをそのままhost kernelへpass-throughするのではなく、Sentryが処理し、必要な場合だけSentry自身が限定されたhost system callを利用する。
この構造によって、通常のcontainerよりもuntrusted applicationからhost kernelへ直接届くattack surfaceを大きく減らすことを狙っている。
runsc はOCI runtime specificationを実装しているため、OCI bundleを通常のcontainer runtimeに近い形で実行できる。DockerやKubernetesのruntimeとして組み込める点が、VM型sandboxに比べた運用上の強みになる。
gVisorにはSentryから外部filesystem accessを仲介するGoferもあり、Sentry自身もseccomp、namespace、cgroupなどを使った制約下で動く。networkについても独自のuserspace network stackであるnetstackを持つ。
一方で、Linuxのすべてのsystem call、/proc、/sys、特殊device interfaceを完全互換で実装しているわけではない。そのため通常のruncと比べてcompatibility差が発生しうる。
ただし2026年4月、TencentはAgentic-RL trainingでgVisorをdefault sandboxとして採用し、productionで1日あたり数百万sandboxを動かしていると報告した。74,000件超のrunsc対runc比較を行い、調査対象の約1.7%でgVisor固有のcompatibility issueを見つけて修正したとしている。これはgVisorがAI code executionの大規模用途でも実運用されている事例として興味深い。
通常containerよりhost kernel exposureを減らしつつ、OCI ecosystemを維持したい場合の中間解として見ると分かりやすい。別guest kernelを使う方式は Kata Containers 4.0はOCI UXのままVM境界を使う、より軽いprocess制約は Landlockは非特権プロセス自身が権限を削るLSM と SandlockはLandlockとseccompを組み合わせた軽量プロセスsandbox。全体比較は Linuxサンドボックスの隔離境界をどう捉えるか。