第4章 系统调用（System Calls）
一、导读
1.1 本章学习目标
理解系统调用的概念及其在操作系统中的核心地位
掌握系统调用从用户态到内核态的完整执行流程
了解系统调用号的分配机制和系统调用表（sys_call_table）的结构
理解系统调用参数的传递方式（寄存器传递）及其限制
掌握 glibc 对系统调用的封装机制及其与原始系统调用的区别
了解添加新系统调用的完整流程和涉及的代码修改
理解系统调用的性能开销及其优化策略
熟悉 Linux 系统调用的安全机制（seccomp、系统调用过滤）
1.2 为什么本章如此重要
系统调用是用户程序与内核交互的唯一合法通道。每一个文件操作、网络通信、进程创建、内存分配，最终都要通过系统调用进入内核完成。理解系统调用的工作机制，是理解操作系统如何保护自身、如何管理资源、如何为用户程序提供服务的关键。
从性能角度看，系统调用的开销不容忽视。每次系统调用都涉及用户态到内核态的切换、寄存器保存与恢复、参数验证等步骤。在高性能服务器中，系统调用可能是主要的性能瓶颈之一。Linux 社区一直在优化系统调用的性能，例如引入 vDSO（Virtual Dynamic Shared Object）使得某些系统调用（如 gettimeofday）可以在用户空间执行，完全避免了模式切换的开销。
从安全角度看，系统调用是内核攻击的主要入口。攻击者通过精心构造的系统调用参数，试图触发内核中的漏洞。因此，内核在系统调用入口处进行了大量的参数验证和权限检查。理解系统调用的安全机制，对于编写安全的应用程序和进行内核安全研究都非常重要。
1.3 核心问题引导
为什么用户程序不能直接访问内核数据结构和硬件，而必须通过系统调用？
系统调用是如何触发从用户态到内核态的切换的？x86 架构上使用什么指令？
系统调用号的作用是什么？为什么不同架构的系统调用号不同？
系统调用最多能传递几个参数？如果需要传递更多数据怎么办？
glibc 的封装函数（如 open()）和实际系统调用（sys_open）之间有什么区别？
添加一个新的系统调用需要修改哪些文件？为什么社区对添加新系统调用非常谨慎？
vDSO 是如何让某些系统调用避免内核切换的？
seccomp 是如何限制进程可以使用的系统调用的？
二、核心概念详解
4.1 系统调用的执行流程
系统调用的执行从用户空间开始。当程序调用一个库函数（如 read()）时，glibc 的封装代码将系统调用号放入指定寄存器（x86-64 上为 rax），将参数分别放入其他寄存器（rdi、rsi、rdx、r10、r8、r9），然后执行 syscall 指令。这条指令触发 CPU 从用户态（Ring 3）切换到内核态（Ring 0），CPU 的指令指针跳转到内核预设的系统调用入口点。
在内核入口点，CPU 首先保存用户空间的寄存器状态（包括栈指针和指令指针）到内核栈上。然后，内核从 rax 中取出系统调用号，在系统调用表中查找对应的处理函数。在调用处理函数之前，内核会进行一系列安全检查：验证系统调用号是否合法、验证用户空间传入的指针是否指向有效的用户空间地址（防止内核空间访问攻击）、检查进程是否有权限执行该操作。
处理函数执行完毕后，将返回值放入 rax 寄存器。内核恢复用户空间的寄存器状态，执行 sysret（或 iret）指令返回用户空间。整个过程对用户程序来说是透明的——程序只是调用了一个函数，但实际上经历了完整的模式切换。
4.2 系统调用表与系统调用号
系统调用表 sys_call_table 是一个函数指针数组，每个元素指向一个系统调用的处理函数。系统调用号就是这个数组的索引。在 x86-64 架构上，系统调用号定义在 <asm/unistd.h> 中。例如，__NR_read 的值为 0，__NR_write 的值为 1，__NR_open 的值为 2。
不同 CPU 架构的系统调用号不同，这是因为每个架构有自己的系统调用 ABI（Application Binary Interface）。例如，read 在 x86 上的系统调用号是 3，而在 x86-64 上是 0。这也是为什么同一个程序在不同架构上需要重新编译——不仅是机器指令不同，系统调用号也不同。
系统调用表在内核源码中通过 syscalls.tbl 文件（或旧版本中的 syscall_table_64.S）定义。每个条目指定系统调用号、处理函数名称和参数类型。内核编译时，这些定义被用来生成系统调用表和相关的胶水代码。
4.3 glibc 封装与 vDSO
glibc 对系统调用的封装不仅仅是简单地执行 syscall 指令。封装函数还需要处理错误码的转换（内核返回负的错误码，glibc 将其转换为正的 errno）、可变参数的处理、64 位参数的拆分（在 32 位系统上）等。例如，open() 的封装会检查 va_arg 获取的 mode 参数，并在系统调用失败时设置 errno。
vDSO（Virtual Dynamic Shared Object）是一种优化机制，使得某些"只读"的系统调用可以在用户空间执行。内核将一小段代码映射到每个进程的用户空间，这段代码可以读取内核通过共享内存更新的时间信息。因此，gettimeofday()、clock_gettime() 等时间相关的系统调用不需要进入内核，直接在用户空间执行，大幅降低了延迟。vDSO 对应用程序完全透明——glibc 会自动检测 vDSO 是否可用，如果可用则使用 vDSO 版本，否则回退到传统系统调用。
4.4 系统调用的安全机制
系统调用是内核安全的关键边界。Linux 提供了多种机制来限制和监控系统调用：
seccomp（Secure Computing Mode）允许进程限制自己可以使用的系统调用集合。一旦启用 seccomp 过滤器，进程尝试调用被禁止的系统调用时，内核会直接终止该进程或返回错误。seccomp 被广泛用于沙箱环境，如 Chrome 浏览器的渲染进程、Docker 容器等。seccomp 过滤器使用 BPF（Berkeley Packet Filter）表达式编写，可以根据系统调用号和参数值进行精细的过滤。
审计子系统（audit）可以记录系统调用的使用情况，用于安全审计和入侵检测。通过配置审计规则，可以监控特定系统调用的调用情况，如谁在访问敏感文件、谁在修改系统配置等。
三、深入分析与讨论
3.1 系统调用的性能开销与优化
一次系统调用的开销通常在几百纳秒到几微秒之间，具体取决于架构和系统调用的类型。开销主要包括：模式切换（syscall/sysret 指令的执行）、寄存器保存与恢复、内核栈切换、参数验证、以及系统调用本身的处理。
Linux 社区采用了多种策略来优化系统调用性能。vDSO 将某些系统调用移到用户空间执行。批量操作接口（如 readv()/writev()、io_uring）减少了系统调用的次数。io_uring 是 Linux 5.1 引入的异步 I/O 接口，它通过共享的环形缓冲区（ring buffer）在用户空间和内核空间之间高效传递 I/O 请求和完成事件，大幅减少了系统调用的次数和上下文切换的开销。
3.2 添加新系统调用的争议
添加新的系统调用到 Linux 内核是一个严肃的决定，需要充分的理由和广泛的社区讨论。原因在于：系统调用接口是内核的 ABI（Application Binary Interface），一旦发布就永远不能删除或修改（向后兼容性保证）。每个系统调用都增加了内核的攻击面和安全审计的工作量。因此，社区倾向于通过 ioctl()、fcntl()、prctl() 等"扩展"系统调用来添加新功能，而不是创建全新的系统调用。
添加新系统调用的流程包括：在邮件列表上提交 RFC（Request for Comments）讨论设计；编写实现代码，包括处理函数和参数验证；更新系统调用表和相关文档；编写手册页（man page）；经过多个版本的审查和修改后合入主线。
四、实践案例
4.1 案例一：使用 strace 分析系统调用
strace 是分析程序系统调用行为的强大工具。通过 strace -c ./program 可以统计程序执行期间各类系统调用的次数和耗时。通过 strace -e trace=open,read,write ./program 可以只跟踪特定的系统调用。例如，分析一个程序的启动过程，可以看到它加载了哪些共享库（open 调用）、读取了哪些配置文件、建立了哪些网络连接。这些信息对于调试程序行为和性能优化非常有价值。
4.2 案例二：使用 seccomp 构建安全沙箱
编写一个程序，使用 prctl(PR_SET_SECCOMP) 或 seccomp() 系统调用启用 seccomp 过滤器，只允许程序使用 read、write、exit 等必要的系统调用，禁止 execve、fork、open 等潜在危险的操作。然后尝试在过滤器启用后调用被禁止的系统调用，观察程序被终止的行为。这种技术被广泛用于容器运行时和浏览器沙箱中，有效限制了漏洞利用的影响范围。
五、常见误区与注意事项
误区：系统调用和库函数是一回事。系统调用是内核提供的原始接口，库函数是 glibc 等 C 库对系统调用的封装。一个库函数可能调用多个系统调用（如 printf() 最终调用 write()），也可能不调用任何系统调用（如 strcpy()）。
误区：系统调用号在所有平台上相同。不同 CPU 架构有不同的系统调用号和 ABI。交叉编译程序时必须使用目标平台的系统调用号。
误区：系统调用的开销可以忽略。虽然单次系统调用的开销很小（几百纳秒），但在高频率调用时（如每秒数百万次的小 I/O），累积开销可能成为性能瓶颈。应考虑使用批量接口或异步 I/O。
注意：系统调用的参数验证是内核安全的关键。内核必须验证用户空间传入的指针确实指向用户空间（而非内核空间），否则攻击者可以利用系统调用读取或修改内核内存。
注意：某些系统调用是"取消点"（Cancellation Point）。在多线程编程中，read()、write()、sleep() 等系统调用是线程取消的取消点，线程可能在这些调用中被取消。
六、本章小结
本章详细讲解了 Linux 系统调用的实现机制。系统调用是用户程序进入内核的唯一合法途径，通过 syscall 指令触发从用户态到内核态的切换。系统调用号和系统调用表将请求路由到正确的处理函数。参数通过寄存器传递，最多 6 个参数。glibc 的封装简化了应用程序开发，处理了错误码转换和平台差异。vDSO 优化使得某些系统调用可以在用户空间执行，避免了模式切换的开销。seccomp 等安全机制限制了进程可以使用的系统调用集合，增强了系统安全性。理解系统调用的底层机制对于性能优化、安全研究和系统调试都至关重要。
七、思考题与练习
使用 strace 跟踪一个简单程序（如 /bin/ls），列出它执行的所有系统调用，分析每个调用的目的。
比较 syscall 指令和传统的中断方式（int 0x80）在 x86 上的性能差异。
设计一个新的系统调用（如 sys_hello），描述需要修改哪些内核文件，写出处理函数的伪代码。
分析 vDSO 的实现原理：内核如何将时间信息传递给用户空间？为什么 gettimeofday() 可以在用户空间执行？
编写一个使用 seccomp 过滤器的程序，只允许 write 和 exit 系统调用，测试过滤器的效果。
研究 io_uring 接口的工作原理，说明它如何减少系统调用的次数。
讨论为什么系统调用接口一旦发布就永远不能更改。这种向后兼容性保证对内核开发有什么影响？
分析系统调用 ioctl() 的设计：为什么它被称为"扩展系统调用"？它的优缺点是什么？