第六篇 系统调用.pptVIP

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