系统调用
操作系统为在用户态运行的进程与硬件设备（如CPU、磁盘、打印机等等）进行交互提供了一组接口。
Unix系统通过向内核发出系统调用（system call）实现用户态进程和硬件设备之间的大部分接口。
POSIX API和系统调用
让我们先强调下应用编程接口（API）与系统调用之间的不同。前者只是一个函数定义，说明了如何获得一个给定的服务；而后者是通过软中断向内核态发出一个明确地请求。
Unix系统给程序员提供了很多API的库函数。libc的标准C库所定义的一些API引用了封装例程（wrapper routine）。通常情况下，每个系统调用对应一个封装例程，而封装例程定义了应用程序使用的API。
系统调用处理程序及服务例程
当用户态的进程调用一个系统调用时，CPU切换到内核态并开始执行一个内核函数。
因为内核实现了很多不同的系统调用，因此进程必须传递一个名为系统调用号（system claa number）的参数来识别所需的系统调用，eax寄存器就用作此目的。当调用一个系统调用时通常还要传递另外的参数。
所有系统调用都返回一个整数值。这些返回值与封装例程返回值的约定是不同的。
在内核中，整数和0表示系统调用成功结束，而负数表示一个出错条件。
在后一种情况下，这个值就是存放在errno变量中必须返回给应用程序的负出错码。内核没有设置和使用errno变量，而封装例程从系统调用返回之后设置这个变量。
系统调用处理程序与其他异常处理程序的结构类似，执行下列操作：
在内核态栈保存大多数寄存器的内容
调用名为系统调用服务例程的相应的C函数来处理系统调用。
退出系统调用处理程序：用保存在内核栈中的值加载寄存器，CPU从内核态切换到用户态。
xyz()系统调用对应的服务例程的名字通常是sys_xyz()。不过也有例外。
为了把系统调用号与相应的服务例程关联起来，内核利用了一个系统调用分派表(dispatch table)。这个表存放在sys_call_table数组中，由NR_syscalls个表项（在Linux2.6.11内核中是289）：第n个表项包含系统调用号为n的服务例程的地址。
NR_syscalls宏只是对可实现的系统调用最大个数的静态限制，并不表示实际已实现的调用个数。
进入和退出系统调用
本地应用可以通过两种不同的方式调用系统调用：
1.执行int $0x80汇编语言指令。在Linux老版本中，这是从用户态切换到内核态的唯一方式。
2.执行sysenter汇编语言指令。
同样，内核可以通过两种方式从系统调用退出，从而使CPU切换回到用户态：
1.执行iret汇编语言指令。
2.执行sysexit汇编语言指令。
通过int $0x80指令发出系统调用
调用系统调用的传统方法是使用汇编语言指令int。
向量128（十六进制0x80）对应于内核入口点。在内核初始化阶段调用的函数trap_init()，用下面的方式建立对于向量128的中断描述符表表项：
set_system_gate(SYSCALL_VECTOR,&system_call);
该调用把下列值存入这个门描述符的相应字段：
Segment Selector:内核代码段__KERNEL_CS的段选择符
Offset:指向system_call()系统调用处理程序的指针
Type:置为15.表示这个异常是一个陷阱，相应的处理程序不禁止可屏蔽中断
DPL:置为3.这就允许用户态进程调用这个异常处理程序
因此当用户态进程发出int $0x80指令时，CPU切换到内核态并开始从地址system_call处开始执行命令。
system_call()函数首先把系统调用好和这个异常处理程序可以用到的所有CPU寄存器保存到相应的栈中。
ENTRY(system_call)
pushl %eax # save orig_eax
SAVE_ALL
GET_THREAD_INFO(%ebp)
# system call tracing in operation
testb $(_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT),TI_flags(%ebp)
jnz syscall_trace_entry
cmpl $(nr_syscalls), %eax
jae syscall_badsys
syscall_call:
call *sys_call_table(,%eax,4) //调用eax中所包含的系统调用号对应的特定服务例程
movl %eax,EAX(%esp) # store the return value
syscall_exit:
cli # make sure we don‘t miss an interrupt
# setting need_resched or sigpending
# between sampling and the iret
movl TI_flags(%ebp), %ecx
testw $_TIF_ALLWORK_MASK, %cx # current->work
jne syscall_exit_work
从系统调用退出
当系统调用服务例程结束时，system_call()函数从eax获得它的返回值，并把这个返回值存放在曾保存用户态eax寄存器值的那个栈单元的位置上。
通过sysenter指令发出系统调用
汇编语言指令int由于要执行几个一致性和安全性检查，所以速度较慢。
sysenter指令
汇编语言指令sysenter使用三种特殊寄存器，它们必须装入下列信息：
SYSENTER_CS_MSR:内核代码段选择符
SYSENTER_EIP_MSR:内核入口点的线性地址
SYSENTER_ESP_MSR:内核堆栈指针
vsyscall页
只要CPU和Linux内核都支持sysenter指令，标准库libc中的封装函数就可以使用它。
进入系统调用
当用sysenter指令发出系统调用时，依次执行下述步骤：
1.标准库中封装例程把系统调用号装入eax寄存器，并调用__kernel_vsyscall()函数。
2.函数__kernel_vsyscall()把ebp、edx和ecx的内容保存到用户态堆栈中，把用户战之中拷贝到ebp中，然后执行sysenter指令。
3.CPU从用户态切换到内核态，内核开始执行sysenter_entry()函数。
4.sysenter_entry()汇编语言函数执行
退出系统调用
当系统调用服务例程结束时，sysenter_entry()函数本质上执行与system_call()函数相同的操作。
首先，它从eax获得系统调用服务例程的返回值，并将返回码存入内核栈中保存用户态eax寄存器值的位置。
然后，函数禁止本地中断，并检查current的thread_info结构中的标志。
如果有任何标志被设置，那么在返回到用户态之前还需要完成一些工作。
sysexit指令
sysexit是与sysenter配对的汇编语言指令：它允许从内核态快速切换到用户态。
SYSENTER_RETURN的代码
SYSENTER_RETURN标记处的代码存放在vsyscall页中，当通过sysenter进入的系统调用被iret或sysexit指令终止时，该页框中的代码被执行。
参数传递
和普通函数类似，系统调用通常也需要输入/输出参数，这些参数可能是实际的值，也可能是用户态进程地址空间的变量，甚至是指向用户态函数的指针的数据结构。
在发出系统调用之前，系统调用的参数被写入CPU寄存器，然后在系统调用服务例程之前，内核再把存放在CPU中的参数拷贝到内核态堆栈中，这是因为系统调用服务例程是普通的C函数。
验证参数
在内核打算满足用户的请求之前，必须仔细地检查所有的系统调用参数。检查的类型即依赖于系统调用，也依赖于特定的参数。
有一种检查对所有的系统调用都是通用的。只要一个参数指定的是地址，那么内核必须检查它是否在这个进程的地址空间之内。由两种可能的方式来执行这种检查：
验证这个线性地址是否属于进程的地址空间，如果是，这个线性地址所在的线性区就具有正确的访问权限。（早期使用）
仅仅验证这个线性地址是否小于PAGE_OFFSET。（从Linux2.2内核开始）
这种粗略的检查是至关重要的，它确保了进程地址空间和内核地址空间都不被非法访问。
对系统调用所传递地址的检查是通过access_ok()宏实现，它由两个分别为addr和size的参数。
#define access_ok(type,addr,size) (likely(__range_ok(addr,size) == 0))
访问进程地址空间
系统调用服务例程需要非常频繁地读写进程地址空间的数据。Linux包含一组宏使这种访问更加容易。我们将描述其中两个名为get_user()和put_user()的宏。第一个宏用来从一个地址读取1、2或4个连续字节，而第二个宏用来把这几种大小的内容写入一个地址。
#define get_user(x,ptr) \
({ int __ret_gu; \
unsigned long __val_gu; \
__chk_user_ptr(ptr); \
switch(sizeof (*(ptr))) { \
case 1: __get_user_x(1,__ret_gu,__val_gu,ptr); break; \
case 2: __get_user_x(2,__ret_gu,__val_gu,ptr); break; \
case 4: __get_user_x(4,__ret_gu,__val_gu,ptr); break; \
default: __get_user_x(X,__ret_gu,__val_gu,ptr); break; \
} \
(x) = (__typeof__(*(ptr)))__val_gu; \
__ret_gu; \
})
#define put_user(x,ptr) \
__put_user_check((__typeof__(*(ptr)))(x),(ptr),sizeof(*(ptr)))
动态地址检查：修正代码
正如当前所看到的，access_ok()宏对系统调用以参数传递来的线性地址的有效性进行了粗略的检查。该检查值保证用户态进程不会试图侵扰内核地址空间。
但是，由参数传递的线性地址依然可能不属于进程地址空间。在这种情况下，当内核试图使用任何这种错误地址时，将会发生缺页异常。
在内核态引起缺页异常的四种情况：
1.内核师徒访问属于进程地址空间的页，但是，或者是相应的页框不存在，或者是内核试图去写一个只读页。在这种情况下，处理程序必须分配和初始化一个新的页框。
2.内核寻址到属于其地址空间的页，但是相应的页表项还没有被初始化。在这种情况下，内核鼻血在当前进程页表中适当建立一些表项。
3.某一内核函数包含编程错误，当这个函数运行时就引起异常；或者，可能由于瞬间的硬件错误引起异常。当这种情况发生时，处理程序必须执行一个内核漏洞。
4.本章所讨论的一种情况：系统调用服务例程试图读写一个内存区，而该内存区的地址是通过系统调用参数传递来的，但却不属于进程的地址空间。
异常表
决定缺页的来源在于内核使用有线的访问访问进程的地址空间。
把访问进程地址空间每条内核指令的地址放到一个叫异常表（excepyion table）的结构中并不用非多大功夫。
当在内核态发生缺页异常时，do_page_fault()处理程序检查异常表：如果表中包含产生异常的指令地址，那么这个错误就是有非法的系统调用参数引起的，否则，就是由某一更严重的bug引起的。
Linux定义了几个异常表。主要的异常表在建立内核程序映像时由C编译器自动生成。它存放在内核代码的__ex_table节，其起始和终止地址由C编译器产生的两个符号__start__ex_table和__stop__ex_table来标识。
每一个异常表的表项是一个exception_table_entry结构，它有两个字段：
insn：访问进程地址空间的指令的线性地址。
fixup：当存放在insn单元中的指令所触发的缺页异常发生时，fixup就是要调用的汇编语言代码的地址。
生成异常表和修正代码
GNU汇编程序（Assembler）伪指令 .section允许程序员指定可执行文件的那部分包含紧接着要执行的代码。
内核封装例程
尽管系统调用主要有用户态进程使用，但也可以被内核线程调用，内核线程不能使用库函数。为了简化相应封装例程的声明，Linux定义了7个从_syscall0到_syscall6的一组宏。
每个宏名字中的数字0~6对应着系统调用所用的参数个数（系统调用号除外）。