linux系统调用过程分析与调试

casualet + 原创作品转载请注明出处 + 《Linux内核分析》MOOC课程http://mooc.study.163.com/course/USTC-1000029000 ”

　　在linux中, 系统调用充当了用户程序和硬件的接口, 它使得用户态程序可以间接执行0特权级的代码, 这种机制是通过中断来实现的, 本文将基于linux内核3.18.6介绍系统调用相关的原理, 并进行代码调试.

一  系统调用为什么能提供保护

 

　  首先, 我们知道x86 CPU提供了0-3四种特权级, linux 内核用到了其中两中, 用户程序在3特权级执行, 而内核在0特权级执行. 但是用户程序又需要访问硬件, 执行内核的代码. 如果运行用户程序直接访问, 则系统安全性不能的到保证. 而用户程序可以执行中断指令, 产生软中断, 然后内核进入中断处理程序,处理中断, 这个中断处理程序, 是0特权级的. 于是, linux在这个地方设置了入口, 提供了一系列的系统调用函数, 用户通过触发中断以及传递参数, 可以切换到0特权级执行, 完成一些0特权级才能完成的功能, 然后函数返回以后, 又恢复到3特权级.

     这种做法和用户直接调用0特权级的代码是不一样的, 如果用户可以直接访问内核的地址空间, 则用户有可能进行修改, 造成系统安全的问题. 但是现在, 用户程序依然不能访问内核的地址空间, 只能通过触发软中断, 在内核可控的条件写执行内核代码.

二  系统调用的执行过程

　  内核实现了很多的系统调用函数, 这些函数会有自己的名字, 以及编号. 用户要调用系统调用, 首先需要使用  int 0x80 触发软中断. 这个指令会在0x80代表十进制的128, 所以这个指令会找终端向量表的128项, 找到以后, 跳转到相应的函数, 这个处理函数就是system_call. 这个中断向量表的设置, 是在操作系统初始化的时候, 通过trap_init()函数设置的.  system_call的代码见 http://codelab.shiyanlou.com/xref/linux-3.18.6/arch/x86/kernel/entry_32.S . 在进入中断处理函数system_call以后, 首先要进行一般的中断处理流程, 即保护现场. 这个体现在指令SAVE_ALL(494行)上. 然后有一个重要的函数调用 call *sys_call_table(,%eax,4). 这个表示查找系统调用函数表(), 然后调用相应的系统调用函数. 对于32位的系统, 函数位置存了4个Bytes, eax中是我们传入的系统调用号, 所以4*eax,就可以找到对应的系统调用函数, 执行函数. 之后还需要进行返回值的保存等工作.

　  完成了上面的第一阶段内容, 我们考虑下图513行的jne syscall_exit_work. 这条指令导致了在系统调用函数执行完以后, 可能会进入syscall_exit_work. 我们先考虑没有进入这个函数的情况. 如果没有进入, 下面就有restore_all, 会进行恢复现场的工作, 这个和刚进入中断处理函数的时候是对应的, 一开始保护现场, 保存了寄存器的值. 现在当然要恢复寄存器到原来的值. 最后通过irq_return: INTERRUPT_RETURN, 效果等同与iret, 返回到用户态程序继续执行.  

　　如果进入了syscall_exit_work, 则可能会进行信号处理以及进程调度. 其基本的流程可以参考下图:

 

      首先, 进入syscall_exit_work以后, 有语句work_pending, 可能会跳转进入work_pending.

　　进入work_pending以后, 我们发现其可能进入work_notifysig(595行), 这里会进行信号处理. 597行的call schedule则是调用进程调度的函数. 注意606行的 jz restore_all, 这个会跳回到restore_all, 跳回以后, 处理流程和上面没有进入syscall_exit_work的情况就是一样的了. 这样我们可以通过下面一个流程图来描述这个系统调用的执行路径(忽略了一些跳转分支以及细节):

 

三  系统调用的调试

　　内核调试的基本设置以及工具等可以参考  http://www.cnblogs.com/syw-casualet/p/5271369.html, 例如我们使用time 系统调用, 可以break sys_time 进行调试. 这样就直接进如了系统调用函数, 然后我们单步执行, 就可以走过上面分析的路径.