现代C: 程序如何与操作系统交互？

在上一讲中我曾提到你可以将操作系统内核暴露的“系统调用”也作为 API 的一种具体表现形式因为调用者可以通过这些接口来使用内核提供的某种能力但是却无需了解它们的内部实现细节。在之前的课程中我也多次提到过有关系统调用的内容。那么系统调用究竟是什么它与我们编写的应用程序函数有何不同通常情况下它又是怎样实现的呢这一讲我们就来看看这些问题的答案。什么是系统调用不知道你还记不记得我在“用于低级 IO 接口的操作系统调用”小节中给出的例子通过这个例子我们能够发现操作系统调用实际上是由操作系统内核封装好的一些可供上层应用程序使用的接口。这些接口为应用提供了可以按照一定规则访问计算机底层软件与硬件相关服务如 IO、进程、摄像头等的能力。其中内核作为中间层隔离了用户代码与硬件体系。接下来我们再通过一个简单的例子来快速回顾下如何在 x86-64 平台上使用系统调用。在大多数情况下位于内核之上的各类系统库如 glibc、musl会将这些系统调用按照不同类别进行封装并提供可以直接在 C 代码中使用的函数接口。通过这种方式我们就可以间接地使用系统调用。当然在这些函数内部系统调用的具体执行通常是由汇编指令 syscall 完成的。比如POSIX 标准中有一个名为 getpid 的函数该函数用于获取当前进程的唯一标识符ID。如果查看 musl 中该函数针对 x86-64 平台的具体实现你会发现这样一段代码#include unistd.h #include syscall.h pid_t getpid(void) { return __syscall(SYS_getpid); }这段 C 代码作为“封装层Wrapper”向上屏蔽了内部的 sys_getpid 系统调用。函数实现中传入的 SYS_getpid 是一个值为 39 的宏常量这个值便为 sys_getpid 系统调用对应的唯一 ID。紧接着通过名为 __syscall 的另一个函数程序可以执行系统调用并获取由内核返回的相关数据。这里该函数直接由汇编代码定义内容如下所示.global __syscall .type __syscall,function __syscall: movq %rdi, %rax movq %rsi, %rdi movq %rdx, %rsi movq %rcx, %rdx movq %r8, %r10 movq %r9, %r8 movq 8(%rsp), %r9 syscall ret在这段 ATT 格式的汇编代码中第 4 行的 movq 指令将传入该函数的系统调用 ID 存放到了 rax 寄存器中接下来的第 5~10 行代码将系统调用需要使用的参数也放到了相应寄存器中这里你可以看到 SysV 规范中对于普通函数和系统调用参数的不同处理方式最后代码的第 11 行通过 syscall 指令系统调用得以被正确执行。可以看到系统调用的使用十分简单。那么你有没有思考过这个问题为什么系统调用需要使用特殊的 syscall 指令而非“普通”的 call 指令进行调用呢想要知道答案那就要先从二者之间不同的代码执行环境开始说起了。系统调用 vs 用户函数系统调用与一般函数或者说“用户函数”的最大区别在于系统调用执行的代码位于操作系统底层的内核环境中而用户函数代码则位于内核之上的应用环境中。这两种环境有时也被称为内核态与用户态。现代计算机通常采用名为“保护环Protection Rings”的机制来保护整个系统的数据和功能使其免受故障和外部恶意行为的伤害。这种方式通过提供多种不同层次的资源访问级别即“特权级别”来限制不同代码的执行能力。比如在 Intel x86 架构中特权级别被分为 4 个层次即 Ring0~Ring3。其中Ring0 层拥有最高特权它具有对整个系统的最大控制能力内核代码通常运行于此。相对地Ring3 层只有最低特权这里是应用程序代码所处的位置。而位于两者之间的 Ring1 和 Ring2 层则通常被操作系统选择性地作为设备驱动程序的“运行等级”。你可以通过下面这张图图片来自 Wikipedia来直观地理解特权级别的概念。根据特权级别的不同CPU 能够被允许执行的机器指令以及可使用的寄存器也有所不同。比如位于 Ring3 层的应用程序可以使用最常见的通用目的寄存器并通过 mov 指令操作其中存放的数据。而位于 Ring0 层的内核代码则可以使用除此之外的 cr0、cr1 等控制寄存器甚至通过 in 与 out 等机器指令直接与特定端口进行 IO 操作。但如果应用程序尝试跨级别非法访问这些被限制的资源CPU 将抛出相应异常阻止相关代码的执行。到这里对于“为什么系统调用需要通过特殊的机器指令来使用”这个问题你应该已经有了答案。系统调用是由内核提供的重要能力而这些能力的具体实现代码属于内核代码的一部分。因此为了执行这些代码我们便需要一种能够在 Ring0 层将它们触发的方法而 syscall 指令便能够做到这一点。最后再让我们来进一步看看系统调用通常是如何实现的。系统调用的基本实现事实上在 x86-64 体系中我们可以采用多种方式来执行一个系统调用。“不遵循 ABI 的程序能否运行”这一小节里的汇编代码为例在不对编译命令做任何修改的情况下你也可以使用下面这段代码来完成同样的工作。extern sub global _start section .text _start: and rsp,0xfffffffffffffff0 sub rsp, 3 mov esi, 2 mov edi, 1 call sub # use int to invoke a system call. mov ebx, eax mov eax, 1 int 0x80观察上述代码的最后三行你会发现我们触发 exit 系统调用的方式发生了变化。int 指令是一个用于产生软中断的汇编指令它在调用时会接收一个中断号作为参数。当中断发生时执行环境会从 Ring3 切换至 Ring0以准备执行内核代码。在这里CPU 会首先根据 int 指令的参数来从名为“中断向量表”的结构中查找下一步需要执行的中断处理程序。这里对于中断号 0x80 来说其对应的中断处理程序便专门用于处理由用户程序发起的系统调用请求。紧接着这个处理程序会根据程序通过寄存器 eax 传入的系统调用号来再次查找待执行的系统调用函数。最后通过 ebx 等寄存器系统调用函数可以获得所需参数并完成内核某段具体代码的执行过程。在这个过程中发生了特权级别的转换因此为了通过隔离执行环境来保证内核安全CPU 在进入内核态前通常还会进行栈的切换。比如在 Linux 中CPU 在用户态与内核态会使用不同的栈来分别处理发生在不同特权级别下的函数调用等过程。每一个进程都对应于独立的内核栈这个栈中会首先存放与用户态代码执行环境相关的一系列寄存器如 esp、eip 等的值。而当发生在内核态的相关过程如系统调用结束后进程使用的栈还需要从内核栈被再次切换回用户栈并同时恢复保存的寄存器值。你可以通过下图来观察上述系统调用的整个执行过程以上便是通过 int 指令来进行系统调用的大致过程。需要注意的是虽然我们可以在 x86-64 体系上使用这种方式但它实际仅适用于 i386 体系。在这里我只是以这种最经典的使用方式为例来向你展现系统调用的一种基本实现原理。而在目前被广泛使用的 x86-64 体系中通过 syscall 指令进行系统调用仍然是最高效也最具兼容性的一种方式。syscall 指令的全称为“快速系统调用Fast System Call”CPU 在执行该指令时不会产生软中断因此也无需经历栈切换和查找中断向量表等过程执行效率会有明显的提升。总结这一讲我主要带你看了三个问题分别是什么是系统调用系统调用与用户函数的区别以及系统调用通常是如何实现的。系统调用是由操作系统内核封装好的一些可供上层应用程序使用的接口这些接口可以让程序方便、安全地通过使用内核的能力来间接地与底层软件和硬件进行交互。与用户函数不同的是系统调用需要 CPU 执行位于内核中的代码而现代计算机采用的“保护环”机制则将整个系统的资源访问能力划分为了多个不同的特权级别。其中Ring0 层拥有最大执行权限它也是内核代码的运行所在。而 Ring3 层则仅有最小权限它是上层应用程序的默认运行层级。系统调用的经典实现方式是通过基于 int 指令的软中断进行的。借助软中断CPU 可以从中断向量表中找到专门用于处理系统调用的中断处理程序而该程序再通过由特定寄存器传入的系统调用号来执行相应的系统调用函数。在这个过程中操作系统通常会进行由用户栈到内核栈的转换以及相关寄存器的存储过程。而在 x86-64 体系中通过 syscall 指令进行的系统调用由于不需要进行软中断和表查询通常会有着更高的执行效率。