chp6 系统调用.ppt

第六章 系统调用 系统调用，顾名思义，说的是操作系统提供给用户程序调用的一组“特殊”接口。 从逻辑上来说，系统调用可被看成是一个内核与用户空间程序交互的接口——它好比一个中间人，把用户进程的请求传达给内核，待内核把请求处理完毕后再将处理结果送回给用户空间。 Linux的应用编程接口（API）遵循 POSIX标准 应用编程接口(API)其实是一组函数定义，这些函数说明了如何获得一个给定的服务；而系统调用是通过软中断向内核发出一个明确的请求 API有可能和系统调用的调用形式一致 API和系统调用关注的都是函数名、参数类型及返回代码的含义 系统调用的实现是在内核完成的，而用户态的函数是在函数库中实现的 系统命令相对应用编程接口更高一层，每个系统命令都是一个可执行程序，比如ls、hostname等， 系统命令的实现调用了系统调用 通过strace ls或strace hostname 命令可以查看系统命令所调用的系统调用 内核函数在形式上与普通函数一样，但它是在内核实现的，需要满足一些内核编程的要求 系统调用是用户进程进入内核的接口层，它本身并非内核函数，但它是由内核函数实现的 进入内核后，不同的系统调用会找到各自对应的内核函数，这些内核函数被称为系统调用的“服务例程” 当用户态的进程调用一个系统调用时，CPU切换到内核态并开始执行一个内核函数 系统调用处理程序执行下列操作： 在内核栈保存大多数寄存器的内容 调用所谓系统调用服务例程的相应的C函数来处理系统调用 通过ret_from_sys_call( )函数从系统调用返回 系统调用的细节 把系统调用进行编号。 形成一张“系统调用表”。 需要调用open()时，先把open()的编号5放在EAX寄存器中，再发生中断。 中断处理程序根据EAX查表，得知需要调用的是open()，而不是其他。 系统调用的细节 比如有这样一段程序 open(); …… read(); …… write(); …… 系统调用的细节 系统调用接口的核心是系统调用多路分解表。这个表如左图所示，使用 eax 中提供的索引来确定要调用该表中的哪个系统调用(sys_call_table) 内核初始化期间调用trap_init( ）函数建立IDT表中128号向量对应的表项： set_system_gate(0x80， system_call); 该调用把下列值装入该门描述符的相应域 ： 段选择子：系统调用处理程序属于内核代码,填写内核代码段__KERNEL_CS的段选择子。 偏移量：指向system_call( )异常处理程序 类型：置为15，表示该异常是一个陷阱 DPL（描述符特权级）：置为3，这就允许用户态进程调用这个异常处理程序 system_call( )函数实现了系统调用处理程序 ： 它首先把系统调用号和该异常处理程序用到的所有CPU寄存器保存到相应的栈中 把当前进程PCB的地址存放在ebx中 对用户态进程传递来的系统调用号进行有效性检查。若调用号大于或等于NR_syscalls，系统调用处理程序终止 若系统调用号无效，函数就把-ENOSYS值存放在栈中eax寄存器所在的单元，再跳到ret_from_sys_call( ) 根据eax中所包含的系统调用号调用对应的特定服务例程 每个系统调用至少有一个参数，即通过eax寄存器传递来的系统调用号 用寄存器传递参数必须满足两个条件： 每个参数的长度不能超过寄存器的长度 参数的个数不能超过6个（包括eax中传递的系统调用号），否则，用一个单独的寄存器指向进程地址空间中这些参数值所在的一个内存区即可 fork( )系统调用并不需要其他的参数。mmap( )系统调用可能需要多达6个参数； int sys_write (unsigned int fd，const char * buf，unsigned int count)。 C编译器产生一个汇编语言函数，该函数可以在栈顶找到fd、buf和count参数，因为这些参数就位于返回地址的下面。 存放系统调用参数所用的6个寄存器以递增的顺序为：eax (存放系统调用号)、 ebx、ecx、edx、esi及edi 服务例程的返回值必须写到eax寄存器中 分析系统调用有两种方法： 查看entry.s中的代码细节，阅读相关的源码来分析其运行过程； 借助一些内核调试工具，动态跟踪执行路径。 结合用户空间的执行路径，该程序的执行大致可归结为以下几个步骤： libc库中如何对不同的服务例程进行封装 ？ Linux定义了从_syscall0到_syscall5的六个宏 每个宏名字的数字0到5对应着系统调用所用的参数个数(系统调用号除外) 每个宏严格地需要2+2?n个