系统调用让这个世界运转

【本文翻译自http://duartes.org/gustavo/blog/post/system-calls/，图片也是拷贝下来的原图，向原作致敬。译者FJ，联系fj_wind^@^126.com】

我真真是不愿意告诉你，一个用户应用程序其实就像一个扎进水缸的脑袋一样，非常无助，一无所知。

每一次和外界的交互都是通过内核的系统调用来完成的。如果一个应用程序要保存一个文件，写数据到终端，或者打开一个TCP连接，都会涉及到内核。应用程序实际上是被高度怀疑的：最好况下都被怀疑成 bug 丛生，最坏的话无异于一个天才恶魔的脑子。

系统调用 (System calls) 是从应用程序到内核的一些函数调用。出于安全的原因，它们采用了具体的机制，但实际上你仅仅是调用了内核的API。“系统调用 (System call) ” 可以指由内核提供的某个具体的函数（如，open()系统调用），或者说这种调用机制。也可以简单的叫做 syscall。

这篇文章将探讨系统调用与库的调用为何不同，还会介绍追踪这种 OS/app 之间接口的工具。扎实地理解了应用程序发生了什么，对应的通过操作系统发生了什么，就能够将一个不可能解决的问题变得快速有趣了。

这儿是一个运行的程序，一个用户进程（~/pid）：

它拥有一个私有的虚拟地址空间，就像是一个自己的内存沙箱。也就是大水缸，如果愿意这样想的话。在它的地址空间中，程序的二进制文件加上它使用的库，都是经过内存映射的。地址空间的一部分映射的是内核本身。

下面是我们程序的代码，pid，简单的通过 getpid(2) 获取到它的进程id：

#include 
#include 
#include 

int main()
{
    pid_t p = getpid();
    printf("%d\n", p);
}

在linux中，一个进程并非天生就知道它的PID。它必须询问内核，所以这需要一次系统调用：

一切都开始于调用 C 库函数 getpid()，它是一个系统调用的包裹函数。当你调用诸如 open(2)，read(2) 这样的函数时，你就是在调用这些包裹函数。很多语言的本地方法最终都是在 libc 之中。

包裹函数在操作系统的裸 API 之上提供了便利，有助于保持内核的简洁（注：内核提供最简单的接口，更复杂的内容就在包裹函数中去实现）。代码所在之处，bug如影随形，所有的内核代码都是在特权模式下运行，任何错误都是灾难性的。任何事情只要能够在用户模式下完成的都应该在用户模式下完成。让库提供友好的方法和很好的参数处理，比如pirntf(3) 。

和web API相比，这类似于为一个服务构建最简单的 HTTP 接口，然后通过 helper 方法提供特定语言的库。或者有可能做一些缓存，这正是 libc 的 getpid() 所做的：当第一次调用它时的确执行了一次系统调用，但是获取到的 PID 会被缓存起来避免在后续调用中的系统调用开销。

一旦包裹函数完成其初始工作，就会陷进内核中去。这种转换的机制会因处理器架构而不同。在 Intel 的处理器上，参数和系统调用的编号会被载入寄存器，接着执行一个指令将 CPU 转换到特权模式，然后立即将控制权交给内核中的全局系统调用入口。如果你对此细节感兴趣，David Drysdale 有两篇很棒的文章。

内核利用系统调用编号作为索引查询 sys_call_table，它是一个包含每个系统调用具体实现的函数指针的数组。现在，sys_getpid 将被调用：

在 Linux 上，系统调用的实现基本上是架构独立的 C 语言函数，有时候则是很简单的，由内核绝佳的设计使其和系统调用的机制完全隔绝。它们只是工作在通用数据结构上的常规代码。好吧，除开完全偏执的参数验证。

一旦它们的工作完成，正常情况下就会 return，然后特定架构的代码会负责转换回用户模式，让包裹函数接着做一些后续处理。在我们的例子中，getpid(2) 会缓存内核返回的 PID。其它的包裹函数可能会设置全局的 errno 变量，如果内核返回一个错误的话。一些小事情让你知道 GNU 关心什么。

如果你想原始一点，glibc 提供了 syscall(2) 这个函数，可以不用包裹函数执行一个系统调用。你也可以自己用汇编来实现。关于 C 库，这儿没有什么神奇的事情或特权。

这种系统调用的设计有着意义深远的重要性。让我们从一个难以置信的有用的命令 strace(1) 开始，这是一个你可以用来侦视系统 Linux 进程所调用的系统调用的工具（在 Mac 上，参考 dtruss(1) 以及 dtrace；在 windows上，参考 sysinternals）。这就是 strace pid 的结果：

~/code/x86-os$ strace ./pid

execve("./pid", ["./pid"], [/* 20 vars */]) = 0
brk(0)                                  = 0x9aa0000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7767000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=18056, ...}) = 0
mmap2(NULL, 18056, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7762000
close(3)                                = 0

[...snip...]

getpid()                                = 14678
fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 1), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7766000
write(1, "14678\n", 614678
)                  = 6
exit_group(6)                           = ?

输出的每一行都显示了一个系统调用，及其参数和返回值。如果你让 getpid(2) 在一个循环中调用1000次，你也只会看到一次 getpid() 系统调用，因为 PID 被缓存了。我们同样可以看到 printf(3) 在格式化好输出字符串后调用了 write(2) 。

strace 命令可以启动一个新的进程，也可以 attach 一个已经运行着的进程。你可以从这些不同的程序所调用的系统调用中学到很多东西。比如说，sshd 这个守护进程整天都在干啥？

~/code/x86-os$ ps ax | grep sshd
12218 ?        Ss     0:00 /usr/sbin/sshd -D

~/code/x86-os$ sudo strace -p 12218
Process 12218 attached - interrupt to quit
select(7, [3 4], NULL, NULL, NULL

[
  ... nothing happens ... 
  No fun, it's just waiting for a connection using select(2)
  If we wait long enough, we might see new keys being generated and so on, but
  let's attach again, tell strace to follow forks (-f), and connect via SSH
]

~/code/x86-os$ sudo strace -p 12218 -f

[lots of calls happen during an SSH login, only a few shown]

[pid 14692] read(3, "-----BEGIN RSA PRIVATE KEY-----\n"..., 1024) = 1024
[pid 14692] open("/usr/share/ssh/blacklist.RSA-2048", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
[pid 14692] open("/etc/ssh/blacklist.RSA-2048", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
[pid 14692] open("/etc/ssh/ssh_host_dsa_key", O_RDONLY|O_LARGEFILE) = 3
[pid 14692] open("/etc/protocols", O_RDONLY|O_CLOEXEC) = 4
[pid 14692] read(4, "# Internet (IP) protocols\n#\n# Up"..., 4096) = 2933
[pid 14692] open("/etc/hosts.allow", O_RDONLY) = 4
[pid 14692] open("/lib/i386-linux-gnu/libnss_dns.so.2", O_RDONLY|O_CLOEXEC) = 4
[pid 14692] stat64("/etc/pam.d", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid 14692] open("/etc/pam.d/common-password", O_RDONLY|O_LARGEFILE) = 8
[pid 14692] open("/etc/pam.d/other", O_RDONLY|O_LARGEFILE) = 4

SSH 是一块大骨头，不过这展示了 strace 的用法。能够查看到应用程序打开了哪个文件是很有用的（“配置文件从哪个鬼地方来的？”）。如果你有一个进程貌似卡住了，你就可以 strace 一把看看它通过系统调用在干什么。有时候一个应用程序意外地退出了，没有留下合适的错误信息，试试看是否某个系统调用失败会给出解释。你也可以使用过滤器，每次调用时间，等等：

~/code/x86-os$ strace -T -e trace=recv curl -silent www.google.com. > /dev/null

recv(3, "HTTP/1.1 200 OK\r\nDate: Wed, 05 N"..., 16384, 0) = 4164 <0.000007>
recv(3, "fl a{color:#36c}a:visited{color:"..., 16384, 0) = 2776 <0.000005>
recv(3, "adient(top,#4d90fe,#4787ed);filt"..., 16384, 0) = 4164 <0.000007>
recv(3, "gbar.up.spd(b,d,1,!0);break;case"..., 16384, 0) = 2776 <0.000006>
recv(3, "$),a.i.G(!0)),window.gbar.up.sl("..., 16384, 0) = 1388 <0.000004>
recv(3, "margin:0;padding:5px 8px 0 6px;v"..., 16384, 0) = 1388 <0.000007>
recv(3, "){window.setTimeout(function(){v"..., 16384, 0) = 1484 <0.000006>

我建议你在自己的操作系统上探索这些工具。把这些工具用好就超神了。

足够有用的东西了，让我们回头看看设计。我们已经看到一个用户级应用程序是被限制在它的虚拟地址空间中以 ring 3（非特权）级别运行的。一般来讲，只与计算和内存访问相关的任务不需要系统调用。例如，C 库中的 strlen(3) 和 memcpy(3) 这些函数与内核不相关。这些任务都是发生载应用程序之中。

man 帮助文档中有关 C 库函数的部分（小括号中的 2 和 3）也提供了线索。第 2 节是系统调用的包裹函数，第 3 节包含了其它的 C 库函数。不过，如我们看到的 printf(3)，一个库函数也可能最终调用一个或多个系统调用。

如果你很好奇，这里有 Linux 上所有的系统调用（同样在 Filippo’s 上的列表）以及Windows。它们分别有大约 310 和 460 个系统调用。看上去很有意思，它们表明了在软件在一个现代计算机上能做的所有事情。另外，你可能会发现诸如进程间通信和性能方面的精髓。这正是 “那些不懂得 UNIX 就注定会重复造车” 的领域。

很多系统调用执行的任务都会花掉超多的 CPU 周期，比方说从一个硬盘读取东西。在这种场景中，调用进程通常会被投入睡眠，直到底层的工作完成。由于 CPU 速度非常之快，你的程序一般情况下是 I/O 密集型的，就会有大多数时间处于睡眠状态，等待系统调用。相比之下，如果你 strace 一个忙于计算型任务的程序，则经常会发现没有产生系统调用。在这种情况下，top(1) 命令会显示巨大的 CPU 使用率。

系统调用带来的开销是一个问题。比如，SSD 已经如此之快以至于操作系统的开销会比 I/O 操作本身还大。程序有大量的读写工作会使操作系统的开销成为其瓶颈。向量 IO 可以帮上忙。内存映射文件也行，允许程序从磁盘中仅通过访问内存就读写数据。类似于视频显卡内存中的映射。Eventually, the economics of cloud computing might lead us to kernels that eliminate or minimize user/kernel mode switches.（译者注：刚开始这句话我没有明白是什么意思，就向作者发邮件询问了一下，下面是作者的答复。我觉得这句话无碍于理解文章主旨，就不翻译了吧）

Yes, that sentence was a bit cryptic. What I meant was this: nowadays we have a lot of cloud servers that only do ONE thing (like they run one web application, for example). In those cases it makes less sense to have a strict separation of OS and programs, since we really care about one program. So perhaps we could eliminate the OS / application barrier, and make the one-and-only running application run in OS mode, to get a little more performance. If we’re talking about thousands of machines, this could make a difference in money and electricity terms. That’s what I meant, hope this clears it up.

最后，系统调用有些有意思的安全实现。有一点就是，无论怎样模糊一个程序的二进制，你仍然可以通过查看它产生的系统调用来检测它的行为。这可以被用作侦测恶意软件。我们也可以记录下一个程序的系统调用使用情况，对其有偏差的行为发出警告，或者为程序提供具体系统调用的白名单，如此使得利用漏洞变得更加困难。我们在此领域有了许多研究，但仅仅是一些列工具，还没有杀手级的解决方法。

以上就是系统调用的内容。写的有些长了，希望有所用处。（后文略）