跟踪分析Linux内核5.0系统调用处理过程
学号223原创作品转载请注明出处
本实验来源 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
编译环境
- 下载内核5.0内核代码,配置编译Linux内核,使之携带调试信息
- 下载内核源码 Linux内核5.0 source code
- 解压到目录中
- 安装编译内核需要的依赖:
sudo apt install bison flex
make menuconfig
,并找到kernel hacking,->Compile-time checks and compiler options,选择 [*]compile the kernel with debug infomake -j4
(4线程加速编译过程)
可以看到已经编译完成,将./linux-5.0/arch/x86/boot/bzImage
拷贝至当前文件夹备用。
此时文件夹内应该已经有下列文件:
- 制作根文件系统
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-i386 -kernel bzImage -initrd rootfs.img -S -s -append nokaslr
注意:-append nokaslr选项的说明见知乎。
运行qemu虚拟机后,在当前目录新建一个终端窗口,运行下列命令:
cd linux-5.0
-
gdb vmlinux
进入gdb界面后,输入target remote:1234
建立与qemu调试端口的attach。
调试过程可以通过gdb内置的c
指令开始,启动初始状态被frozen的虚拟机内核。
- 分析
首先,几乎所有的内核模块均会在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时间片,并且从不返回。
跟踪系统调用
- 首先选择学号后两位的系统调用(学号223):
- 然后编写下列2个文件,比较系统API和汇编执行过程:
/*setUid.c*/
#include<unistd.h>
#include<stdio.h>
int main(void){
int i = 65535, k = 0;
i = getuid();
printf("curent user id is:%d\n", i);
setuid(200);
k = getuid();
printf("after change uid:%d\n", k);
return 0;
}
/* setUidAsm.c */
#include<unistd.h>
#include<stdio.h>
int main(void){
int i = 65535, j = 200, k = 0;
asm volatile(
"mov $0,%%ebx\n\t"
"mov $0x18,%%eax\n\t" /* 调用24号系统调用,即getUid,显示当前uid状态 */
"int $0x80\n\t"
"mov %%eax,%0\n\t"
:"=m"(i)
);
printf("current user id is:%d\n", i);
asm volatile(
"mov $0,%%ebx\n\t"
"mov $0x17,%%eax\n\t" /* 调用23号系统调用,即setUid,设置该程序uid */
"mov %1,%%ebx\n\t"
"int $0x80\n\t"
"mov %%eax,%0\n\t"
:"=m"(i)
:"c"(j)
);
asm volatile(
"mov $0,%%ebx\n\t"
"mov $0x18,%%eax\n\t" /* 调用24号系统调用,即getUid,显示当前uid状态 */
"int $0x80\n\t"
"mov %%eax,%0\n\t"
:"=m"(k)
);
printf("after change user id is:%d\n", k);
return 0;
}
使用gcc -o setUid setUid.c
命令编译后,分别使用当前用户和root用户(加上sudo)运行程序:
可以看出,使用不同的用户运行该程序有不同的效果,至于原理请自行搜索setuid linux
。
再使用gcc -o setUidAsm setUidAsm.c
编译我们的汇编版本调用,并分别使用当前用户和root用户(加上sudo)运行程序:
可以发现,汇编版本的也运行成功。
实验代码以及过程分析
系统调用:
操作系统为用户态进程与硬件设备进行交互提供了一组接口——系统调用 :
- 把用户从底层的硬件编程中解放出来
- 极大的提高了系统的安全性
- 使用户程序具有可移植性
API调用:
应用编程接口(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()。