第五周 扒开系统调用的“三层皮”（下）

一、知识点总结

（一）给MenuOS增加time和time-asm命令

在实验楼中，首先

1. 强制删除menu (rm menu -rf)
2. 重新克隆一个新版本的menu(git clone https://github.com/mengning/menu.git
3. 进入menu之后，输入make rootfs，就可以自动编译，自动生成根文件系统
4. 输入help，可以发现系统支持更多的命令：help version quit time（显示系统时间） time-asm（汇编方式实现）
5. 如何实现time和time-asm？
• 更新menu代码到最新版
• test.c中main函数里，增加MenuConfig()
• 增加对应的两个函数，Time和TimeAsm函数
• make rootfs自动编译脚本
• 

下图为在虚拟机中的设置

（二）使用gdb调试跟踪系统调用内核函数sys_time

该过程在第三周已经详细讲解过，这里不做赘述，过程如下：

• 为处理time函数的系统调用systime设置断点之后，在menuOS中执行time。发现系统停在systime处。继续按n单步执行，会进入schedule函数。
• sys_time返回之后进入汇编代码处理，gdb无法继续跟踪。
• 如果在syscall设置断点（entry32.S），然后输入c之后，发现是不会在sys_call处停下来的（因为这里是一处系统调用函数而不是正常函数）。

（三）系统调用在内核代码中的处理过程

1.系统调用在内核代码中的工作机制和初始化

整个系统调用过程中，时间很重要。
以system_call为例，int 0x80指令与systemcall是通过中断向量联系起来的，而API和对应的sys是通过系统调用号联系起来的

用户态时，系统调用xyz()使用int 0x80，它对应调用system_call

右边的处理过程（汇编代码）非常重要，通过系统调用号匹配起来

2.系统调用机制的初始化

trap_init函数里面有一个set_system_trap_gate函数，其中涉及到了系统调用的中断向量SYSCALL_VECTOR和汇编代码入口system_call，一旦执行int 0x80，CPU直接跳转到system_call来执行。

3.简化后便于理解的system_call伪代码

1. systemcall的位置就在ENTRY（systemcall）处，其他中断的处理过程与此类似。

• SAVE_ALL：保存现场

• call *sys_call_table(,%eax,4)调用了系统调度处理函数，eax存的是系统调用号，是实际的系统调度程序。
  • sys_call_table：系统调用分派表

• syscall_after_all：保存返回值

• 若有sys_exit_work，则进入sys_exit_work:会有一个进程调度时机。
  • work_pending -> work_notifysig，用来处理信号
    • 可能call schedule：进程调度代码
    • 可能跳转到restore_all，恢复现场。

• 若无sys_exit_work，就执行restore_all恢复，返回用户态。

• INTERRUPT_RETURN <=> iret，结束。

这段代码有几百行，老师用伪代码简化了下

SAVE_ALL与sys_call_table系统调用分派表，对应的处理函数分别是：

sys_call_table(,%eax,4)

JMP(EAX*4 + system_xxx)

1.在系统调用返回之前，可能发生进程调度，进程调度里就会出现进程上下文的切换
2.进程间通信可能有信号需要处理

4.简单浏览system_call到iret之间的主要代码

1. SAVE_ALL：保存现场
2. syscall_call:调用了系统调用处理函数
3. restore all：恢复现场（因为系统调用处理函数也算是一种特殊的“中断”）
4. syscallexitwork：如3.中所述
5. INTERRUPT RETURN：也就是iret，系统调用到此结束

二、实验：分析system_call中断处理过程

（一）使用gdb跟踪分析一个系统调用内核函数（上周选择的系统调用）——getuid

1.先执行rm menu -rf，强制删除原有的menu文件夹，使用git命令更新menu代码至最新版。

2.在test.c中添加C函数、汇编函数

3.make rootfs，输入help，可以看到qemu中增加了我们先前添加的命令：

4.可以看到，getuid和getud_asm已经加进去了，分别执行这两个系统调用：

（二）使用gdb跟踪分析一个系统调用内核函数

1.进入gdb调试

2.给start_kernel处设置断点

3.结果如下

4.查看所选用的系统调用函数，可知断点要设置在这里

5.执行命令getuid时没有停下

6.c运行之后，在MenuOs里使用getuid_asm，可以看到它在执行时停下了

7.结束若干次单步执行，然后继续往下单步执行，发现出现了进程调度函数，返回进程调度中的一个当前进程任务的值

8.list可以查看内部的函数，直到system_call返回后进入汇编代码处理，gdb无法继续进行追踪

（三）system_call到iret过程流程图

三、总结

（一）从系统调用处理过程到一般的中断处理过程

1. 保存现场

• 在系统调用时，用SAVE_ALL来保存系统调用时的上下文。
• 中断处理的第一步也是要保存中断程序现场。
• 中断处理完之后，可以返回到原来被中断的地方，在原有的运行环境下继续正确的执行下去。

2. 确定中断信息

• 在系统调用中，需要将系统调用号通过eax传入，通过sys_call_table查询到调用的系统调用，然后跳转到相应的程序进行处理。
• 中断处理时系统也需要有一个中断号，通过检索中断向量表，了解中断的类型和设备。

3. 处理中断

• 跳转到相应的中断处理程序后，对中断进行处理。

4. 返回

• 系统调用时最后要restore_all恢复系统调用时的现场，并用iret返回用户态。
• 同样，执行完中断处理程序，内核也要执行特定指令序列，恢复中断时现场，并使得进程回到用户态。

（二）给menuOS增加命令的方法：

• 强制删除menu (rm menu -rf)
• 更新menu代码至最新版本（git clone https://github.com/mengning/menu.git）
• 在test.c中main函数中增加MenuConfig,以及增加上周自己选择Getegid,GetegidAsm的代码
• Make roofts自动编译，生成，和启动根文件系统

（三）使用gdb跟踪调试内核的方法：

qemu -kernel linux-3.18.6/arch/x86/boot/bzImage -initrd rootfs.img -s -S 

gdb

（gdb）file linux-3.18.6/vmlinux # 在gdb界面中targe remote之前加载符号表

（gdb）target remote:1234 # 建立gdb和gdbserver之间的连接,按c 让qemu上的Linux继续运行

（gdb）break start_kernel # 断点的设置,注意寻找对应的系统调用函数名字，例如time命令对应sys_time

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

Linux内核分析——第五周学习笔记20135308

原文：http://www.cnblogs.com/bonjourvivi/p/5314902.html