gvisor通过用户态sentry内核接管并重处理所有系统调用，实现容器与宿主机内核的物理隔离：白名单过滤约200个常用调用、语义重写虚拟化响应、上下文审计记录行为；再叠加seccomp前置拦截，构成“双闸门”纵深防御，但不支持ptrace、perf_event_open等高危或高级特性。
用 gVisor 隔离系统调用，本质是把容器和宿主机内核“物理隔开”——不是靠规则拦，而是让调用根本到不了内核。它不修改内核、不依赖复杂策略，而是用一个用户态的轻量“内核”（Sentry）来接管所有系统调用，真正从源头缩小攻击面。
为什么系统调用隔离必须做？
默认 runc 容器里，应用一发 open()、ioctl() 或 ptrace()，就直通宿主机内核。Linux 内核有 300+ 个系统调用接口，哪怕只暴露其中 5% 的高危路径（比如 init_module、create_module），就可能被用于加载恶意模块或逃逸。去年 Dirty Pipe 漏洞爆发时，所有共享该内核的容器都面临风险——而 gVisor 容器完全不受影响，因为它的 Sentry 根本不实现这些调用。
gVisor 是怎么拦截并重处理系统调用的？
Sentry 是核心执行单元，它在用户空间模拟内核行为，对每个系统调用做三件事：
-
白名单过滤：只响应约 200 个常用调用（如
read、write、mmap），其余一律返回ENOSYS或直接拒绝 -
语义重写：比如
open("/proc/cpuinfo")不会读宿主机文件，而是由 Sentry 返回虚拟化后的 CPU 信息 - 上下文审计：记录调用来源 PID、参数长度、触发时间，为异常行为检测提供原始日志
如何配合 seccomp 实现双重防护？
gVisor 本身已大幅收窄系统调用面，但生产环境建议再叠一层 seccomp 白名单——不是为了补漏，而是构建纵深防御链：
- seccomp 在 OCI 运行时加载，早于 Sentry 启动，可拦截非法 syscall 进入 gVisor 流程
- 例如禁用
clone()的CLONE_NEWUSER标志，防止容器内尝试嵌套命名空间 - 典型策略中保留
read/write/close/exit_group，其余全拒，配合 gVisor 的 Sentry 过滤，形成“双闸门”机制
实际部署要注意哪些兼容性边界？
gVisor 不是万能内核替代品，它刻意放弃部分高级能力来换取安全与可控性：
-
不支持：
ptrace（调试工具如strace失效）、perf_event_open（性能分析受限）、io_uring（异步 I/O 新特性暂未实现） -
受限支持：GPU 相关
ioctl需显式放行，且仅限 NVIDIA Container Toolkit v1.12+ 场景 - 推荐场景：无状态 Web 服务、数据处理流水线、多租户 SaaS 前端、金融类 API 网关——这些应用几乎不依赖底层硬件交互
