第五章 系统调用

5.1 与内核通信

系统调用在用户空间进程和硬件设备之间添加了一个中间层。该层主要作用有三个。

• 它为用户空间提供了一种硬件的抽象接口。
• 系统调用保 证了系统的毡定和安全。
• 在第 3 章中曾经提到过，每个进程都运行在虚拟系统中，而在用户空间和系统的其余部分提供这样一层公共接口，也是出于这种考虑。

在 Linux 中，系统调用是用户空间访问 内核的唯一手段：除异常和陷入外，它们是内核唯一的合法入口。

5.2 API, POSIX 和 C 库

应用程序通过在用户空间实现的应用编程接口（API）而非直接通过系统调用来编程。

POSIX是应用编程接口的一个国际标准，C库提供了POSIX的绝大部分API。

POSIX、API、C库和系统调用之间的关系图

5.3 系统调用

要访问系统调用（在 Linux 中常称作 syscall），通常通过 C 库中定义的函数调用来进行。

5.3.1 系统调用号

1. 在 Linux 中，每个系统调用被赋予一个系统调用号。这样，通过这个独一无二的号就可以关 联系统调用。当用户空间的进程执行一个系统调用的时候， 这个系统调用号就用来指明到底是要 执行哪个系统调用：进程不会提及系统调用的名称。
2. 系统调用号相当重要， 一旦分配就不能再有任何变更，否则编译好的应用程序就会崩溃。
3. 内核记录了系统调用表中的所有已注册过的系统调用的列表，存储在 sys_call_ table 中。
4. 这个表为每一个有放的系统调用指定了唯一的系统调用号。

5.3.2 系统调用的性能

Linux 系统调用比其他许多操作系统执行得要快。 Linux很短的土下文切换时间是一个重要原因，迸出内核都被优化得简洁高效。另外一个原因是系统调用处理程序和每个系统调用本身也 都非常简洁。

5.4系统调用处理程序

用户空间的程序无法直接执行内核代码，所以以某种方式通知系统，告知内核自己要系统调用，让系统切换到内核状态。

1．通知内核的机制是靠软中断实现的：

通过引发一个异常来促使系统切换到内核态去执行异常处理程序，此时的异常处理程序实际上就是系统调用处理程序，在×86系统上预定义的软中断是中断号128。通过int￥0X80指令触发该中断，这条指令会触发一个异常导致系统切换到内核态并执行第128号异常处理程序，而该程序正是系统调用处理程序，这个处理程序名字起得很贴切，叫system_call().它与硬件体系结构紧密相关。

2．指定恰当的系统调用

（1）所有的系统调用陷入内核方式都一样，并必须把系统调用号一并传给内核。

（2）在x86上，系统调用号是通过eax寄存器传递给内核的。

（3）system_call()函数通过将给定的系统调用号与NR_syscall比较检查有效性。

（4）执行相应的系统调用：call *sys_call_table(,%rax,8)

3．参数传递

（1）x86-32系统，ebx,ecx,edx,esi,edi按顺序存放前五个参数。

（2）需要6个及以上参数时，应用一个单独的寄存器存放指向所有这些参数在用户空间地址的指针。

（3）给用户空间的返回值也通过寄存器传递。在x86系统上，它存放在eax寄存器中。

5.5系统调用的实现

1. 实现系统调用

第一步决定用途，不提倡采用多用途的系统调用；

注意：

  1.系统调用的接口应该力求简洁，参数尽可能少。

  2.很多系统调用提供了标志参数以确保向前兼容。标志并不是用来让单个系统调用具有多个不同的行别如前所述，这是不允许的，而是为了即使增加新的功能和选项，也不破坏向后兼容或不需要增加新的系统调用。

  3.系统调用设计得越通用越好。不要假设这个系统调用现在怎么用将来也一定就是这么用。系统调用的目的可能不变，但它的用法却可能改变。

  4.可移植性和健壮性要好，要确保不对系统调用做错误的假设，否则将来这个调用就可能会崩溃。

2. 参数验证

检查所有参数是否合法有效而且正确。进程不应当让内核去访问那些它无权访问的资源。

最重要的一种检查就是检查用户提供的指针是否有效。在接收一个用户空间的指针之前，内核必须保证：

（1）指针指向的内存区域属于用户空间，进程决不能哄骗内核去读内核空间的数据。

（2）指针指向的内存区域在进程的地址空间里，进程决不能哄骗内核去读其他进程的数据。

（3）如果是读，该内存应被标记为可读；如果是写，该内存应被标记为可写；如果是可执行，该内存被标记为可执行。进程绝不能绕过内存访问权限。

完成检查和在内核空间和用户空间之间数据的来回拷贝的两个方法：

向用户空间写入数据：copy_to_user()：

从用户空间读取数据：copy_from_user()：