SYSCALL_USER_DISPATCH：从内核原语到 gVisor 风格轻量级沙箱

2021 年 Linux 内核 5.11 引入了一个看似不起眼但影响深远的特性：SYSCALL_USER_DISPATCH。它让 Userspace 拦截系统调用不再需要 ptrace 的重量级上下文切换，也无需编写复杂的 seccomp-BPF 字节码。作为 gVisor 新一代防护模式的基础原语，它标志着内核安全子系统向"委托式拦截"迈出了关键一步。本文将深入剖析其内核实现机制、用户态 API 设计，并构建一个完整的最小化安全沙箱原型。

一、问题背景：系统调用拦截的三十年演进

操作系统安全的永恒命题之一是：如何安全地在操作系统和应用程序之间充当"守门人"？系统调用是用户空间请求内核服务的唯一入口，拦截并审查系统调用是实现沙箱隔离的基础手段。

回顾历史，三代方案各有局限：

ptrace 的致命性能问题使其完全不适用于容器化场景——每次系统调用需要两次完整的 CPU 上下文切换（内核 → tracer → tracee），开销可达数微秒。而 seccomp-BPF 虽然性能优异，但其字节码执行环境受限：无法执行阻塞操作、无法修改 syscall 参数、返回值只能选择 SECCOMP_RET_ALLOW/KILL/ERRNO 等有限选项，无法用其构建完整的 syscall 模拟层。

gVisor 最初采用 ptrace 模式实现 syscall 拦截（称为 ptrace 模式），随着用户数量增长，性能成为瓶颈。社区急需在"内核执行时上下文切换少"和"用户态灵活控制"之间找到平衡点——这正是 SYSCALL_USER_DISPATCH 的设计目标。

二、核心机制：内核如何"委托"系统调用

2.1 基本设计思想

SYSCALL_USER_DISPATCH 的核心理念极其简洁：内核不执行 syscall，也不阻止它，而是直接发送 SIGSYS 信号给用户态，让用户态程序自行决定该怎么做。

具体流程如下：

1. 进程通过 prctl(PR_SET_SYSCALL_USER_DISPATCH, ...) 注册一个"选择器范围"——一组被监控的系统调用号集合
2. 当目标进程中的线程执行某个被选中的系统调用时，内核不会进入 syscall handler
3. 取而代之的是，内核构造 siginfo_t 结构体（sig = SIGSYS，si_code = SYS_USER_DISPATCH）并投递信号
4. 进程的 SIGSYS 信号处理器接收该信号，从中取出 syscall 号、参数等信息
5. 用户态处理完成后，通过修改 ucontext 中的寄存器状态来决定：继续执行该 syscall 的模拟版本、修改参数让其进入内核、或直接忽略

这种"委托式"设计将决策权完全留给用户态，同时保持了几乎等同于原生 syscall 的执行路径——没有额外的上下文切换，没有 VMExit，没有 ptrace 的两次切换。

2.2 内核实现要点

从内核视角看，SYSCALL_USER_DISPATCH 的实现主要位于 kernel/entry/common.c 和 arch/x86/entry/ 路径中，核心逻辑可以用伪代码表示：

// arch/x86/entry/common.c (简化版)
static long do_syscall(struct pt_regs *regs, unsigned int nr)
{
    // 检查进程是否启用了 SYSCALL_USER_DISPATCH
    if (current->seccomp.mode == SECCOMP_MODE_STRICT_DISPATCH) {
        // 判断该 syscall 号是否在选择器范围内
        if (in_dispatch_range(nr)) {
            // 构造 SIGSYS 信号
            siginfo_t info;
            info.si_signo = SIGSYS;
            info.si_code  = SYS_USER_DISPATCH;
            info.si_call_nr = nr;
            info.si_syscall_addr = regs->ip;  // 触发syscall的指令地址
            
            // 向目标线程发送信号，暂停syscall执行
            force_sigsys(SIGSYS, &info);
            
            // 返回 -ENOSYS 作为占位符，实际由用户态接管
            return -ENOSYS;
        }
    }
    
    // 正常路径：进入系统调用 handler
    return syscall_enter_from_user_mode(regs, nr);
}

关键点在于：内核的逻辑是非阻塞的。它不等待用户态处理结果，而是直接发信号并返回。这种"fire-and-forget"方式保证了内核侧实现极简——事实上并未引入新的 scheduler hooks 或进程状态机变更。

2.3 选择器模式（Selector）

每个进程在启用 SYSCALL_USER_DISPATCH 时需要指定一个 selector 值，这个值写入 MSR_LSTAR（syscall entry MSR）对应的 spec_ctrl flag 中。selector 本质上是一个布尔标志：当 selector 置位时，系统调用触发内核侧的选择逻辑；清零时则走正常 syscall 路径，避免不必要的信号投递。

这使得 selector 的切换成为关键性能点——在 gVisor 的实现中，可以动态切换 selector 状态，确保只有"沙箱内"的代码段才会触发 dispatch。

---

三、用户态 API：从零构建 Syscall Dispatch Handler

3.1 核心系统调用接口

启用 SYSCALL_USER_DISPATCH 需要两个步骤：

步骤 1：设置 selector

#include <sys/prctl.h>
#include <linux/seccomp.h>

// PR_SET_SYSCALL_USER_DISPATCH = 61
int prctl(int option, unsigned long arg2, unsigned long arg3,
          unsigned long arg4, unsigned long arg5);

参数说明：

• option: PR_SET_SYSCALL_USER_DISPATCH
• arg2: selector 值（0 表示禁用，非0 启用）
• arg3: 被监控系统调用号范围的起始值
• arg4: 被监控系统调用号范围的结束值
• arg5: 通常为 0（保留参数）

步骤 2：注册 SIGSYS 处理函数

struct sigaction act = {
    .sa_sigaction = sigsys_handler,
    .sa_flags = SA_SIGINFO | SA_NODEFER,
};
sigaction(SIGSYS, &act, NULL);

必须设置 SA_SIGINFO 以获取完整的 siginfo_t 和 ucontext_t；SA_NODEFER 防止在 handler 中触发 SIGSYS 时递归死锁。

3.2 完整的 Dispatch Handler 实现

下面是一个最小化的 syscall dispatch 框架，展示如何拦截 read() 并模拟返回：

#include <signal.h>
#include <ucontext.h>
#include <unistd.h>
#include <sys/syscall.h>

void sigsys_handler(int sig, siginfo_t *info, void *ucontext)
{
    ucontext_t *ctx = (ucontext_t *)ucontext;
    
    // 从 siginfo 获取系统调用号
    int syscall_nr = info->si_syscall_nr;
    
    // 从 ucontext 获取系统调用参数（x86_64 ABI）
    // rdi = arg0, rsi = arg1, rdx = arg2, r10 = arg3
    long arg0 = ctx->uc_mcontext.gregs[REG_RDI];
    long arg1 = ctx->uc_mcontext.gregs[REG_RSI];
    long arg2 = ctx->uc_mcontext.gregs[REG_RDX];
    
    switch (syscall_nr) {
    case SYS_read: {
        int fd = (int)arg0;
        void *buf = (void *)arg1;
        size_t count = (arg2);
        
        // 拦截对 fd=0 (stdin) 的读取，模拟返回 EOF
        if (fd == 0 && is_sandboxed_fd(fd)) {
            // 设置返回值 (REG_RAX)
            ctx->uc_mcontext.gregs[REG_RAX] = 0;  // 返回 0 字节
            
            // 跳过原始 syscall 指令，继续执行下一条用户态指令
            ctx->uc_mcontext.gregs[REG_RIP] += 2;  // syscall 指令是 2 字节
        } else {
            // 对非拦截 syscall：恢复 selector 执行真正的 syscall
            prctl(PR_SET_SYSCALL_USER_DISPATCH, 0, ...);  // 临时禁用
            
            // 手动执行真正的 read()
            long ret = read(fd, buf, count);
            ctx->uc_mcontext.gregs[REG_RAX] = ret;
            
            // 恢复 selector
            prctl(PR_SET_SYSCALL_USER_DISPATCH, 1, ...);
            ctx->uc_mcontext.gregs[REG_RIP] += 2;
        }
        break;
    }
    
    default:
        // 未知 syscall：根据策略决定
        ctx->uc_mcontext.gregs[REG_RAX] = -ENOSYS;
        ctx->uc_mcontext.gregs[REG_RIP] += 2;
        break;
    }
}

3.3 寄存器操作的 ABI 依赖

SYSCALL_USER_DISPATCH 的跨架构可移植性是个挑战。不同架构下 syscall 参数、返回值的寄存器映射完全不同。x86_64 的映射如下：

寄存器	用途
rax	系统调用号 / 返回值
rdi	第 1 个参数
rsi	第 2 个参数
rdx	第 3 个参数
r10	第 4 个参数（注意：不是 rcx）
r8	第 5 个参数
r9	第 6 个参数

在生产环境中（如 gVisor），通常使用 libseccomp 或直接对架构敏感的汇编来实现跨平台兼容。

---

四、gVisor 实战：Sentry 如何使用 Syscall User Dispatch

4.1 架构背景

gVisor 的 Sentry（用户态内核）组件原本通过 ptrace 拦截所有系统调用。这种模式下，每次进程执行 syscall 都会触发 VMExit 级的上下文切换（实际上是 ptrace 内核态切换），并需要：

1. 读取 tracee 的寄存器状态
2. 判断是否需要模拟
3. 模拟后写回寄存器
4. PTRACE_SYSCALL 恢复执行

这个过程动辄数千个 CPU 时钟周期，对于 I/O 密集的微服务来说不可接受。

4.2 Gofer 模式的替代思路

gVisor 探索过多种优化路径，核心思路是将 syscall 拦截的开销从"每次切换"降到尽可能低的水平。SYSCALL_USER_DISPATCH 提供了一种新的可能：

• 避免 ptrace 内核进入/退出开销：不再进入 kernel ptrace handler，只在用户态发信号
• 减少内核态操作：无需内核态模拟逻辑，所有模拟在用户态完成（用户态模拟本来就是 gVisor 的做法）
• 保留 seccomp 的选择性优势：只对需要拦截的 syscall 范围启用 dispatch，其余 syscall 正常执行

目前 gVisor 已将 SYSCALL_USER_DISPATCH 作为可选沙箱模式之一。用户可以通过 flag 启用，结合 fsgofer 的文件系统代理模式，实现接近原生性能的文件 I/O 沙箱。

4.3 性能基准对比

根据 gVisor 社区的测试数据（简化的 syscall 密集型负载）：

模式	getpid() 开销（ns）	read() 开销（ns）	相对性能
原生（无沙箱）	85	200	1.0x
ptrace 模式	35,000	78,000	~200x
seccomp-BPF (allow策略)	95	220	~1.1x
SYSCALL_USER_DISPATCH	800	1,500	~5-8x
KVM 模式	400	900	~3-5x

可见 SYSCALL_USER_DISPATCH 性能显著优于 ptrace 模式，但劣于 KVM。其代价主要来自：信号投递的软中断开销 + 用户态 handler 执行 + selector 切换的 prctl 系统调用。对于以少量阻塞 syscall 为主的应用，这种开销完全可接受。

---

五、与 seccomp-BPF 的协同使用

SYSCALL_USER_DISPATCH 通常不是孤立使用的。在实际部署中，它往往与 seccomp-BPF 配合实现分层安全策略：

5.1 分层模型

应用代码执行 syscall
       ↓
┌─────────────────────────────────┐
│ 第一层：seccomp-BPF 快速过滤    │  ← 内核态，几乎零开销
│  - 允许所有常见 syscall         │
│  - 阻断危险 syscall (reboot等)  │
│  - 需模拟的 syscall → TRAP/ERRNO│
└─────────────────────────────────┘
       ↓ (如果 seccomp 通过)
┌─────────────────────────────────┐
│ 第二层：SYSCALL_USER_DISPATCH   │  ← 用户态信号，中等开销
│  - 读取 info->si_syscall_nr     │
│  - 构建模拟响应                 │
│  - 或修改参数后重试             │
└─────────────────────────────────┘
       ↓
┌─────────────────────────────────┐
│ 第三层：容器运行时隔离           │  ← 硬件强制
│  - namespace (mnt/pid/net)      │
│  - cgroup (资源限制)            │
│  - capability                   │
└─────────────────────────────────┘

这种分层设计使得大多数"正常"syscall 永远不需要进入 dispatch handler——它们在第一层就被 seccomp 放行。只有少数需要文件系统代理、网络代理的 syscall 才会触发 SIGSYS 进入 dispatch 处理，从而最大化性能。

5.2 错误处理最佳实践

在生产代码中，SIGSYS handler 需要特别注意以下陷阱：

1. 递归信号：handler 内部如果执行了被监控的 syscall，会再次触发 SIGSYS。必须通过 selector 禁用或维护 per-thread "in handler" 标志。
1. thread safety：SIGSYS 是 thread-directed 信号，只会投递给执行 syscall 的线程。但 handler 中如果修改全局状态，仍需使用原子操作。
1. siginfo 有效性窗口：siginfo_t 和 ucontext_t 只在 handler 执行期间有效。如需保存 syscall 上下文做异步处理，必须先 deepcopy。
1. 架构差异：ARM64 使用 x0-x5 传参，MIPS 使用 $a0-a3。跨平台代码需要条件编译。

---

六、调试与排错

6.1 诊断信号未到达问题

如果 SIGSYS handler 没有被调用，按以下顺序排查：

# 1. 确认 PR_SET_SYSCALL_USER_DISPATCH 调用成功
strace -e prctl ./your_sandbox_prog
# 期望看到: prctl(0x39 /* PR_??? */, 1, 0, 0x2000028, 0) = 0

# 2. 确认信号处理器已注册
grep SigBlk /proc/[pid]/status
# SIGSYS 不应被 block

# 3. 使用 perf 追踪 sigsys 事件
perf trace -e signal:signal_generate ./your_sandbox_prog
# 期望看到 SIGSYS 信号生成记录

6.2 常见错误及修复

错误现象	原因	修复
handler 被调用两次	selector 未在 handler 入口禁用	handler 起始处先 prctl(disable)
SIGSYS 导致核心转储	handler 返回后 ucontext 损坏	确保 orig_rax/rax 正确设置
SIGSYS 被信号掩码阻塞	多线程程序未正确设置	SIG_UNBLOCK SIGSYS 在所有线程
selector 切换延迟高	prctl 被频繁调用	每 batch 操作只切换一次

6.3 GDB 调试技巧

在 GDB 中调试 SIGSYS handler 的最佳实践：

# 设置 SIGSYS 的 pass 和 print
handle SIGSYS stop print

# 在 handler 入口设置您的断点
b sigsys_handler

# 检查 siginfo 内容
p *info
p ctx->uc_mcontext.gregs[REG_RAX]
p ctx->uc_mcontext.gregs[REG_RIP]  # 触发 syscall 的地址

---

七、未来展望

SYSCALL_USER_DISPATCH 仍在活跃演进中。当前内核社区正在讨论几个重要扩展方向：

1. per-thread selector：目前 selector 是进程范围的全局标志。未来的 PR_SET_SYSCALL_USER_DISPATCH_EX 可支持 per-thread 级别，这是多线程异步 I/O 场景的刚需。
1. syscall 参数修改后重试：当前模式下必须自己模拟或通过 prctl(on) + 重新 syscall 的方式执行真正的内核调用。未来可能引入 SYSCALL_USER_DISPATCH_RETRY_FLAG 让内核用修改后的参数重新执行 syscall，减少一次额外的 syscall。
1. 与 io_uring 的集成：io_uring 已经展示了批量 syscall 提交的性能优势。与 SYSCALL_USER_DISPATCH 的结合可能实现：在 dispatch handler 中批量模拟多个 I/O syscall，只需一次真正的 io_uring_enter 提交，将 dispatch 开销从"每 syscall"降到"每 batch"。
1. eBPF 集成：Google 团队曾提交 RFC：将 SIGSYS 信号交由 eBPF 程序处理，避免用户态 handler 注册。这可以进一步减少开销，但需要精心设计的 verifier 策略。

---

总结

SYSCALL_USER_DISPATCH 填补了"内核态快速过滤"与"用户态完整控制"之间的技术空白。它的设计哲学值得借鉴——内核仅提供"轻量级通知机制"，将复杂决策逻辑交给用户态，既保持内核极简，又赋予部署灵活性。

对于构建自定义沙箱的开发者，推荐的分层策略是：seccomp-BPF 处理 95% 的快速路径，SYSCALL_USER_DISPATCH 处理 5% 需要模拟的 syscall，配合 namespace + capability 提供硬件级纵深防御。这种组合已经能够在生产环境中实现接近 ptrace 模式 40 倍的性能提升，同时保持完整的安全语义。

Linux 安全子系统仍在快速演进，从 mmap_lock 到 io_uring_security hook，再到 SYSCALL_USER_DISPATCH，每一次 API 扩展都在重新定义"用户态可操作"的边界。对性能敏感的安全从业者而言，关注这些新原语的学习曲线远低于其带来的架构红利。