gVisor 深度解读

Google 开源的”用户态内核”，不用 KVM 也能隔离。

一句话定位

在用户空间重新实现 Linux 系统调用接口，拦截所有应用行为，不需要硬件虚拟化——Google 的”第三条隔离路线”哲学实验。

设计哲学上最精彩的地方

gVisor 的核心理念是：隔离不一定需要硬件虚拟化，只需要”翻译层”。

类比：你在一家餐厅吃饭（应用），不直接接触厨房（内核），而是通过服务员（Sentry）点菜。服务员翻译你的需求给厨房，过滤掉你不能点的菜，然后把做好的菜端给你。你永远不碰厨房。

这个翻译层叫 Sentry，它是用 Go 写的、运行在用户态的完整 Linux 内核替代品。

Sentry 的技术特点

• 不是 syscall filter（如 seccomp-bpf），因为 seccomp 只做黑白名单
• 不是 wrapper（如 firejail），因为 wrapper 还是在 host 内核上运行
• 是一个真正的应用内核——实现了 Linux syscall 的绝大部分语义
• 用 Go 写 → 内存安全（不像 C 内核有缓冲区溢出风险）

gVisor 的竞争价值

它解决了 KVM-based 方案的一个根本性约束：需要虚拟化支持。不是所有云环境都有 KVM（某些 VPS、某些容器环境），gVisor 可以直接跑在普通 Docker 里。启动速度是进程级的（毫秒级），不需要 boot 一个 VM。

代码量巨大的原因

因为要在用户态重新实现 Linux 内核的几万个 syscall 行为。gVisor 是 6 个项目里代码量最大的（”数千文件”），这也是它的代价——每新增一个 syscall 都要在 Sentry 里实现一遍。

gVisor 的实际应用

• Google 内部用于 GKE 的 Pod 沙箱化
• 与 Kubernetes 集成（runsc runtime）
• 适合”不需要最强隔离，但需要比 Namespace 更强的隔离”的场景

关键洞察

gVisor 和 Firecracker 解决的是同一个问题（隔离不可信代码），但路线完全不同：

• Firecracker：用硬件隔离，性能极致，但需要 KVM
• gVisor：用软件隔离，灵活度高，但 syscall 兼容性有边界

在 AI Agent 代码执行场景下，gVisor 的边界尤其明显：如果 Agent 代码跑了一些需要特殊 syscall 的操作（如某些 ML 库的优化路径），Sentry 可能不支持或性能很差。

本地代码结构

gvisor/
  runsc/               — OCI 运行时入口（替代 runc）
  pkg/                 — 核心包（数千文件）
    sentry/            — 用户态内核实现（Go）
    tcpip/             — 网络栈（完整 TCP/IP 实现）
    seccheck/          — 安全策略检查
  g3doc/               — 文档和 logo
  docs/                — 用户文档

本地关键文件