基于ptrace的系统调用拦截结果与strace不一致的原因排查

我通过Rust的nix crate使用ptrace功能拦截子进程的系统调用，代码能正常运行且目标进程行为符合预期，但拦截到的系统调用列表与strace对同一确定性目标进程的输出存在差异。运行环境为Ubuntu 20.04（strace 5.5、Rust 1.72.1、nix crate 0.28.0）。

可能的差异原因 #

1. Syscall跟踪阶段的处理差异 #

Strace默认会捕获系统调用的进入和退出两个阶段，但最终输出的是系统调用完成后的结果（包含返回值）。如果你的ptrace代码只处理了其中一个阶段（比如仅跟踪进入时的PTRACE_SYSCALL事件，未处理退出），会导致拦截到的syscall数量翻倍或缺失。

另外，Linux内核在syscall被信号中断后会触发restart_syscall（x86_64编号120），这个内核内部的syscall会被Strace默认过滤，但你的代码如果没有显式过滤，会将其计入拦截结果。

2. Ptrace跟踪选项的配置差异 #

Strace会默认启用PTRACE_O_TRACESYSGOOD选项，该选项会让syscall触发的SIGTRAP信号带上0x80的掩码，以此区分普通陷阱和syscall陷阱。如果你的代码未设置该选项，可能会将其他调试陷阱（比如断点）误判为syscall事件，或者漏识别部分syscall。

通过nix crate设置该选项的代码示例：

use nix::sys::ptrace;
use nix::sys::wait::WaitStatus;

// 在附着子进程后设置选项
ptrace::setoptions(child_pid, ptrace::Options::PTRACE_O_TRACESYSGOOD).unwrap();

3. Strace的默认过滤规则 #

Strace会自动过滤掉一些对用户态无意义的内部syscall，比如：

• 动态链接器ld-linux初始化阶段的部分syscall（如arch_prctl、gettid的重复调用）
• 内核用于线程同步的futex调用（特定场景下）
• 进程信号处理相关的隐式syscall

而你的ptrace代码会捕获所有内核暴露的syscall事件，不会自动过滤这些内容，导致结果数量更多。

4. 子进程启动的ptrace附着时机 #

如果你的代码在fork子进程后，没有正确同步ptrace的附着流程，可能会漏掉目标进程启动初期的syscall（比如execve本身的后续初始化调用）。正确的流程应该是：

1. 父进程fork子进程
2. 子进程调用ptrace::traceme()，然后执行execve启动目标程序
3. 父进程调用waitpid等待子进程进入停止状态，再开始跟踪syscall

如果附着时机滞后，会丢失子进程启动阶段的部分syscall。

5. 架构相关的Syscall编号处理 #

在x86_64架构下，syscall进入时rax寄存器存储的是syscall编号，退出时rax存储的是返回值。如果你的代码没有区分这两个阶段，可能会把返回值误判为syscall编号，或者重复统计同一个syscall的进入和退出事件。

验证与修复建议 #

• 启用PTRACE_O_TRACESYSGOOD，通过信号掩码区分syscall事件和普通陷阱
• 在代码中显式过滤restart_syscall等内核内部syscall
• 区分syscall的进入和退出阶段，仅记录完成后的syscall（和Strace逻辑对齐）
• 检查子进程启动时的ptrace附着流程，确保没有遗漏启动初期的syscall

内容的提问来源于stack exchange，提问作者Florian Brucker