2018-2019-1 20189210 《LInux内核原理与分析》第五周作业

一、系统调用实验
1、库函数将系统调用封装起来，大多数程序员使用库函数进行系统调用。
2、Linux操作系统的体系架构分为用户态和内核态。CPU的执行级别对应的就是内核态，所有指令都可以执行。用户态对应的就是低级别指令。
3、系统调用也是一种中断，中断处理是从用户态进入内核态的主要方式，系统调用是一种特殊的中断。
4、库函数就是操作系统提供的API（应用程序编程接口），API只是函数定义。系统调用是通过软中断向内核发出了中断请求，int指令的执行就会触发一个中断请求。libc函数库定义的一些API内部使用了系统调用的封装例程（用于发布系统调用），使程序员不需要汇编指令来触发系统调用。
5、大部分的系统调用的封装例程会返回一个整数，其值的含义依赖于对应的系统调用，返回值-1表示内核不能满足进程的请求，0表示能够满足。
6、系统调用的三层机制：xyz()（API）、system_call(所有系统调用的入口) 、 sys_xyz()(中断服务程序)。
7、系统调用是用户进入内核的接口，并非内核函数。用户程序通过某个系统调用进入内核后，会接着去执行这个系统调用对应的内核函数。这个内核函数 sys_xyz() 称为系统调用的服务例程。
8、系统调用号将 xyz() 与 sys_xyz() 关联起，系统调用号由 eax 寄存器传递。

  本实验使用的是系统调用号为 38 的 sys_rename()，功能实现设计为将hello.c 文件重新命名 newhello.c

（1）库函数API实现：
系统调用rename，在内核中的系统调用处理函数为 sys_rename，其 函数原型：
asmlinkage long sys_rename(const char __user *oldname,const char __user *newname);
可以看出需要传递两个参数，一个是旧文件名，一个是新文件名。由于是指针类型，所以此时的文件名也代表该文件，也就是说，先找到叫 oldname 的文件，然后把其名改为 newname。rename() 是 glibc 对sys_rename 的封装，用户在用户态调用 rename(),将 oldname和newname 参数传入，系统会产生中断陷入内核态执行sys_rename。当重命名成功时，函数返回0。
（2）嵌入汇编代码实现：
asm volatile("movl %2,%%ecx\n\t" //newname存入ecx
"movl %1,%%ebx\n\t" //oldname存入ebx
"movl $0x26,%%eax\n\t" //系统调用号存入eax
"int $0x80" //执行系统调用
:"=a"(ret)
:"b"(oldname),"c"(newname)
);
  把系统调用号38(16进制是0x26)存入 eax，将 oldname 存入 ebx，将 newname 存入 ecx，通过执行 int $0x80 来执行系统调用，使应用程序陷入内核态，system_call 根据传入的系统调用号在系统调用列表中查找对应的内核函数，根据 ebx 和 ecx 中保存的参数调用内核函数 sys_rename，执行完后将执行结果存放到 eax 中,最后返回 eax 中的值。
2、将“=a”换成 “=m“。

可以看出helko.c确实变成了newhello.c，但却显示没有修改成功，即ret不等于0.既然确实执行了sys_rename，返回值0就应该保存在eax中，返回采用的是“=m”,并没有将0保存进内存。

API方法实现系统调用实现非常便捷，只需知道函数原型即可，有很好的移植性。但是，如果 glibc 没有封装某个内核提供的系统调用时，就没办法通过此方法来调用内核函数。我可以利用 glibc 提供的syscall 函数直接调用。函数原型为long int syscall (long int sysno, ...)sysno 是系统调用号，在 sys/syscall.h 中有所有可能的系统调用号的宏定义。代码改为（SYS_rename换成38也正确）：

小结：
本周学习了系统调用的原理和实验，如果用户态要涉及内核态的操作，就需要通过系统调用来实现。应用程序在用户态调用 API 函数，系统调用号和参数保存到 eax，ebx 等寄存器中，通过 0x80 中断向量触发中断陷入内核态，中断服务程序根据系统调用号调用并执行对应的内核函数，执行完毕后将结果存放的 eax 中并返回给程序，程序返回用户态。