分析Linux内核5.0系统调用处理过程

学号300原创作品转载请注明出处
本实验来源 https://github.com/mengning/linuxkernel/

---

一、实验要求

举例跟踪分析Linux内核5.0系统调用处理过程

编译内核5.0
qemu -kernel linux-5.0.1/arch/x86/boot/bzImage -initrd rootfs.img
选择系统调用号后两位与您的学号后两位相同的系统调用进行跟踪分析
https://github.com/mengning/menu
给出相关关键源代码及实验截图，撰写一篇博客（署真实姓名或学号最后3位编号），并在博客文章中注明“原创作品转载请注明出处 + https://github.com/mengning/linuxkernel/ ”，博客内容的具体要求如下：
题目自拟，内容围绕系统调用进行；
博客中需要使用实验截图
博客内容中需要仔细分析系统调用、保护现场与恢复现场、系统调用号及参数传递过程
总结部分需要阐明自己对系统调用工作机制的理解。

二、实验环境

• Ubuntu 18.04 LTS
• gcc 7.3.0

三、编译环境

• 下载内核源码 Linux内核5.0 source code https://mirrors.edge.kernel.org/pub/linux/kernel/v5.x/linux-5.0.1.tar.xz
• 解压到目录中
• 安装编译内核需要的依赖：sudo apt install bison flex
• make menuconfig，并找到kernel hacking，->Compile-time checks and compiler options，选择 [*]compile the kernel with
  debug info
• make -j8 （j8加速编译过程)
  
  
  

可能遇到的问题

解决：sudo apt-get install libncurses-dev

解决：sudo apt-get install libssl-dev

在我的虚拟机上面编译大概需要2个小时左右才能完成

制作根文件系统

• cd …
• mkdir rootfs
• git clone https://github.com/mengning/menu.git
• cd menu
• sudo apt install gcc-multilib
• gcc -pthread -o init linktable.c menu.c test.c -m32 -static
• cd …/rootfs
• cp …/menu/init ./
• find . | cpio -o -Hnewc | gzip -9 > …/rootfs.img

启动MenuOS

根据老师的提示把命令qemu-system-i386 -kernel bzImage -initrd rootfs.img换成qemu-system-x86_64 -kernel arch/x86/boot/bzImage -initrd rootfs.img

跟踪调试内核启动

• qemu-system-x86_64 -kernel arch/x86/boot/bzImage -initrd rootfs.img -S -s -append nokaslr
• 在当前目录新建一个终端窗口，运行下列命令
• gdb vmlinux
  进入gdb界面后，输入target remote:1234建立与qemu调试端口的attach
• target remote:1234
• b start_kernel
• c

分析

几乎所有的内核模块均会在start_kernel进行初始化。在start_kernel中，会对各项硬件设备进行初始化，包括一些page_address、tick等等，直到最后需要执行的rest_init中，会开始让系统跑起来。那rest_init这个过程中，会调用kernel_thread()来创建内核线程kernel_init，它创建用户的init进程，初始化内核，并设置成1号进程，这个进程会继
续做相关的系统初始化。然后，start_kernel会调用kernel_thread并创建kthreadd，负责管理内核中得所有线程，然
后进程ID会被设置为2。最后，会创建idle进程（0号进程），不能被调度，并利用循环来不断调号空闲的CPU时间片，
并且从不返回。

四、跟踪系统调用

1. 选用学号后两位的系统调用(学号：300)，所以选择0号系统调用，该系统函数名为restart_syscall
   

    		Name restart_syscall
    		Synopsis（函数原型）: long sys_restart_syscall(void);
    		Description（函数描述）:restart_syscall is a helper function that restarts a system call
    		Return Value（返回值）: returns the return value of the system call it restarts
   

2. 编写300.c文件，调用系统函数

 #include <unistd.h>
 #include <sys/syscall.h>
 #include <sys/types.h>
 #include <signal.h>
 #include <stdio.h>
 #include <stdlib.h>
 
 int  main(int argc, char *argv[])
 {
      pid_t tid;
      pid_t  tid_b;
      tid_b = SYS_restart_syscall;
      printf("tid_b:%d ...\n",tid_b);

      tid = syscall(SYS_gettid);
      printf("tid : %d\n",tid);
 
      tid = syscall(SYS_tgkill, getpid(), tid, SIGHUP);
      printf("tid : %d ...\n",tid);
    
      tid_b = SYS_restart_syscall;
      printf("tid_b:%d ...\n",tid_b);
      return 0;
 }

编译文件 输入命令 gcc -g 300.c -o 300 -m32

调试跟踪

gdb -q
file 300
b syscall （设置断点）
r
ni
info r （查看寄存器的值）
ni
info r （查看寄存器的值是否发生改变）

过程分析

操作系统为用户态进程与硬件设备进行交互提供了一组接口——系统调用 ：
1.把用户从底层的硬件编程中解放出来 2.极大的提高了系统的安全性 3.使用户程序具有可移植性
应用编程接口（Application program interface,API)和系统调用是不同的，API只是一个函数定义系统调用通过软中断向内核发出一个明确的请求。Libc库定义的一些API引用了封装例程（wrapper routine，唯一目的就是发布系统调用）一般每个系统调用对应一个封装例程库再用这些封装例程定义出给用户的API不是每个API都对应一个特定的系统调用API可能直接提供用户态的服务（如，一些数学函数）。一个单独的API可能调用了几个系用调用，不同的API可能调用同一个系统调用

五、实验总结

Linux系统就是通过内核发出的系统调用（system call）实现了用户态进程和硬件设备之间的大部分接口。计算机系统的各种硬件资源是有限的，在现代多任务操作系统上同一时候执行的多个进程都须要訪问这些资源，为了更好的管理这些资源进程是不同意直接操作的，全部对这些资源的訪问都必须有操作系统控制。也就是说操作系统是使用这些资源的唯一入口，而这个入口就是操作系统提供的系统调用（System Call）。在linux中系统调用是用户空间訪问内核的唯一手段，除异常和陷入外，他们是内核唯一的合法入口。普通情况下应用程序通过应用编程接口API，而不是直接通过系统调用来编程。操作系统通常是通过中断从用户态切换到内核态。中断就是一个硬件或软件请求，要求CPU暂停当前的工作，去处理更重要的事情。比方。在x86机器上能够通过int指令进行软件中断。而在磁盘完毕读写操作后会向CPU发起硬件中断。中断有两个重要的属性，中断号和中断处理程序。中断号用来标识不同的中断，不同的中断具有不同的中断处理程序。在操作系统内核中维护着一个中断向量表（Interrupt Vector Table）。这个数组存储了全部中断处理程序的地址，而中断号就是对应中断在中断向量表中的偏移量。一般地，系统调用都是通过软件中断实现的，x86系统上的软件中断由int $0x80指令产生，而128号异常处理程序就是系统调用处理程序system_call()