本文详细介绍了在Ubuntu环境下，如何为arm64架构编译Linux内核、BusyBox，创建根文件系统，并配置调试环境，特别是使用QEMU和gdb进行远程调试。此外，还深入分析了gettimeofday系统调用的执行流程，包括用户态到内核态的转换、异常处理和系统调用返回的过程。
文章目录
一、准备工作
1.安装编译工具链
由于ubuntu系统是基于x86架构的，要在上面编译arm64内核，需要安装交叉编译工具链，使用如下命令进行安装
sudo apt-get install gcc-aarch64-linux-gnu
sudo apt-get install libncurses5-dev build-essential git bison flex libssl-dev
2.编译busybox
cd ~/busybox-1.31.1/
# 引入环境变量, 基于arm64架构编译
export ARCH=arm64
export CROSS_COMPILE=aarch64-linux-gnu-
# 修改配置文件
make menuconfig
# 记得要编译成静态链接，不用动态链接库。
Settings --->
[*] Build static binary (no shared libs)
# 编译busybox并安装
make -j$(nproc) && make install
3.制作根文件系统
本次实验制作根文件系统的步骤与上一个实验基本一致，具体可以参考Linux操作系统分析Lab3
最终生成的根文件系统压缩包命名为rootfs_arm64.cpio.gz
4.修改配置文件，使Linux内核基于arm64架构进行编译
cd linux-5.4.34/
make defconfig ARCH=arm64
make menuconfig ARCH=arm64
# 打开debug相关选项，按Y选中，按N取消选中
Kernel hacking --->
Compile-time checks and compiler options --->
[*] Compile the kernel with debug info
[*] Provide GDB scripts for kernel debugging
[*] Kernel debugging
# 关闭KASLR，否则会导致打断点失败
Kernel Features ---->
[] Randomize the address of the kernel image (KASLR)
# save保存，exit退出
5.编译内核
# 引入环境变量, 基于arm64架构编译
export ARCH=arm64
export CROSS_COMPILE=aarch64-linux-gnu-
# 内核编译
make -j$(nproc)
6.启动测试
启动测试QEMU环境，通过gdb remote功能，链接QEMU并调试内核。有一点需要注意，由于我们调试的是ARM64模拟环境，需要使用"gdb-multiarch"而不是ubuntu自带的gdb工具，如果系统没有可以通过下面命令安装
sudo apt-get install gdb-multiarch
qemu可能由于版本过低而无法正常启动arm64内核，这里下载4.21版本的qemu
sudo apt-get install build-essential zlib1g-dev pkg-config libglib2.0-dev binutils-dev libboost-all-dev autoconf libtool libssl-dev libpixman-1-dev
wget https://download.qemu.org/qemu-4.2.1.tar.xz
tar xvJf qemu-4.2.1.tar.xz
cd qemu-4.2.1
./configure --target-list=x86_64-softmmu,x86_64-linux-user,arm-softmmu,arm-linux-user,aarch64-softmmu,aarch64-linux-user --enable-kvm
make
sudo make install
启动qemu
qemu-system-aarch64 -m 128M -smp 1 -cpu cortex-a57 -machine virt -kernel ~/linux-5.4.34/arch/arm64/boot/Image -initrd ~/rootfs_arm64.cpio.gz -append "rdinit=/init console=ttyAMA0 loglevel=8" -nographic -s -S
打开另外一个终端窗口，使用gdb进行调试
gdb-multiarch linux-5.4.34/vmlinux
(gdb) target remote:1234 # tcp建立连接
(gdb) b start_kernel # 设置断点
c、bt、list、next、step.... # gdb的一些调试命令,
调试部分截图如下，可以看到能够正常调试
7.配置VSCode下的调试环境
在纯命令行下进行调试不是很方便，因此配置VSCode环境进行Linux内核的调试。在上个实验中已经配置了VSCode的相关文件，这里只需修改一下即可，修改后的文件如下
/*launch.json*/
{
// launch.json
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "(gdb) linux",
"type": "cppdbg",
"request": "launch",
"preLaunchTask": "vm",
"program": "${workspaceRoot}/vmlinux",
"miDebuggerPath":"/usr/bin/gdb-multiarch",
"miDebuggerServerAddress": "localhost:1234",
"args": [],
"stopAtEntry": true,
"cwd": "${workspaceFolder}",
"environment": [],
"externalConsole": false,
"MIMode": "gdb",
"miDebuggerArgs": "-n",
"targetArchitecture": "x64",
"setupCommands": [
{
"text": "dir .",
"ignoreFailures": false
},
{
"text": "add-auto-load-safe-path ./",
"ignoreFailures": false
},
{
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
]
}
]
}
/*tasks.json*/
{
// See https://go.microsoft.com/fwlink/?LinkId=733558
// for the documentation about the tasks.json format
"version": "2.0.0",
"tasks": [
{
"label": "vm",
"type": "shell",
"command": "qemu-system-aarch64 -m 128M -smp 1 -cpu cortex-a57 -machine virt -kernel arch/arm64/boot/Image -initrd ../rootfs_arm64.cpio.gz -append \"rdinit=/init console=ttyAMA0 loglevel=8\" -nographic -s",
"presentation": {
"echo": true,
"clear": true,
"group": "vm"
},
"isBackground": true,
"problemMatcher": [
{
"pattern": [
{
"regexp": ".",
"file": 1,
"location": 2,
"message": 3
}
],
"background": {
"activeOnStart": true,
"beginsPattern": ".",
"endsPattern": ".",
}
}
]
},
{
"label": "build linux",
"type": "shell",
"command": "make",
"group": {
"kind": "build",
"isDefault": true
},
"presentation": {
"echo": false,
"group": "build"
}
}
]
}
二、分析gettimeofday系统调用
通过内嵌汇编代码来触发系统调用，在ARM64架构下Linux系统调用由同步异常svc指令触发。当用户态（EL0级）程序调用库函数gettimeofday从而触发系统调用的时候，先把系统调用的参数依次放入X0-X5这6个寄存器（这里仅这里仅需要使用X0和X1两个寄存器），然后把系统调用号放在X8寄存器里，最后执行svc指令，CPU即进入内核态（EL1级），代码如下
#include <stdio.h>
#include <time.h>
#include <sys/time.h>
int main()
{
time_t tt;
struct timeval tv;
struct tm *t;
#if 0
gettimeofday(&tv,NULL); // 使用库函数的方式触发系统调用
#else
asm volatile( // 使用内嵌汇编的方式触发系统调用
"add x0, x29, 16\n\t" //X0寄存器用于传递参数&tv
"mov x1, #0x0\n\t" //X1寄存器用于传递参数NULL
"mov x8, #0xa9\n\t" //使用X8传递系统调用号169
"svc #0x0\n\t" //触发系统调用
);
#endif
tt = tv.tv_sec; //tv是保存获取时间结果的结构体
t = localtime(&tt); //将世纪秒转换成对应的年月日时分秒
printf("time: %d/%d/%d %d:%d:%d\n",
t->tm_year + 1900,
t->tm_mon,
t->tm_mday,
t->tm_hour,
t->tm_min,
t->tm_sec);
return 0;
}
将文件命名为test.c，然后编译成在arm64下的可执行文件
aarch64-linux-gnu-gcc -o test test.c -static
此时在当前目录下新生成了一个可执行文件test，把它复制到之前制作的根文件系统根目录下，重新打包
接下来在VSCode中对gettimeofday系统调用进行分析，首先设置断点__arm64_sys_gettimeofday，然后启动调试，等内核启动后，在终端执行test，然后就可以使用gdb对gettimeofday的过程进行调试分析了
用户态程序执行svc指令，CPU会把当前程序指针寄存器PC放入ELR_EL1寄存器里，把当前状态PSTATE放入SPSR_EL1寄存器里，把异常产生的原因（这里是调用了svc指令触发系统调用）放在ESR_EL1寄存器里。这时CPU是知道异常类型和异常向量表的起始地址的，所以可以自动计算得出该异常向量空间的入口地址，然后跳转到那里执行异常向量空间里面的指令。异常向量空间最后一条指令是b指令，对于用户态的系统调用来说会跳转到el0_sync，这样就从异常向量空间跳转同步异常处理程序的入口
kernel_entry 0用于保存用户态寄存器信息(x0~x30/sp/pc/spsr等)到内核栈。然后根据异常类型调用其他函数。这里程序发生了系统调用（gettimeofday），因此会调用el0_svc
在el0_svc中，首先保存一些上下文环境，然后调用el0_svc_handler继续处理系统调用，并在调用完成后调用ret_to_user返回系统调用
在el0_svc_handler中，调用el0_svc_common继续处理系统调用。el0_svc_common函数第1个参数regs是内核堆栈栈底的部分，主要是传递过来了系统调用参数x0-x5；第2个参数regs->regs[8]是指x8寄存器传递过来的系统调用号；第3个参数__NR_syscalls是指当前系统的系统调用总数，我们目前分析的ARM64 Linux 5.4.34内核的系统调用总数为436个；第4个参数sys_call_table则是以系统调用号作为下标的系统调用内核处理函数的数组
将参数继续传递给invoke_syscall函数，并通过syscall_fn函数来执行真正的异常处理程序，最后将系统调用的返回值存储在内核堆栈x0寄存器中，以便在系统调用返回时可以传递到用户态x0寄存器
在系统调用完成后，el0_svc会调用ret_to_user函数返回系统调用。在系统调用返回前会处理一些工作（work_pending），比如处理信号、判断是否需要进程调度等，ret_to_user的最后是kernel_exit 0负责恢复现场，与保存现场kernel_entry 0相对应，kernel_exit 0的最后会执行eret指令系统调用返回。eret指令所做的工作与svc指令相对应，eret指令会将ELR_EL1寄存器里值恢复到程序指针寄存器PC中，把SPSR_EL1寄存器里的值恢复到PSTATE处理器状态中，同时会从内核态转换到用户态，在用户态堆栈栈顶指针sp代表的是sp_el0寄存器
arm64的系统调用过程可以总结如下
用户触发了一个系统调用，然后系统检查到这个调用就会执行处理程序，首先硬件会自动保存当前执行程序的堆栈状态，以便恢复现场，接着根据中断向量号来决定具体执行哪一个系统调用，在执行完真正的中断处理程序后，会返回调用，并恢复现场和寄存器、堆栈等的状态
三、实验总结
这次实验以gettimeofday为例分析了arm64系统调用背后发生的过程，了解了arm64架构下系统调用是怎么保存现场，处理、执行系统调用和返回系统调用的，与课堂上所学知识结合起来，加深了我对arm64系统调用的理解
参考资料：
系统调用实现原理
armv8/arm64 中断/系统调用流程
作者：518
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
