Linux- 分析 time/gettimeofday 系统调用在 ARM64 Linux 中的执行过程

基于VS Code的Linux内核调试环境搭建及start_kernel跟踪分析_青衫客36的博客-CSDN博客我们已经搭建了基于 x86 的 Linux 内核调试环境。搭建 ARM64 的调试环境和 x86 大同小异，本部分仅列出有差异的地方。

一、实验准备

首先，由于个人电脑几乎都是使用基于 x86 架构的处理器，要编译和调试 ARM64 环境，必须安装交叉编译工具链和跨平台版 gdb，命令如下：

sudo apt-get install gcc-aarch64-linux-gnu
sudo apt-get install libncurses5-dev  build-essential git bison flex libssl-dev
sudo apt install gdb-multiarch

其次，我们需要为 ARM64 新建一个内核编译配置文件，对这个新配置文件进行修改。

make defconfig ARCH=arm64
make menuconfig ARCH=arm64

和 x86 一样在菜单中选择如下编译配置，注意部分选项的位置略有不同。

Kernel hacking  --->
    Compile-time checks and compiler options  --->
        [*] Compile the kernel with debug info
        [*]   Provide GDB scripts for kernel debugging
    [*] Kernel debugging
Kernel Features ---->
    [] Randomize the address of the kernel image

另外 ，在前一篇文章的基础上还需要在终端提前 export 交叉编译选项再 make（否则编译的还是 x86 的内核），命令如下。

export ARCH=arm64
export CROSS_COMPILE=aarch64-linux-gnu-
make Image -j$(nproc) # 这里指定target为Image，只编译kernel不会编译modules，加快编译速度

接下来制作内存根文件系统：

cd busybox-1.31.1/

在编译前设置编译选项：

export ARCH=arm64
export CROSS_COMPILE=aarch64-linux-gnu-

然后配置编译选项：

make menuconfig

设置编译选项：

Settings  --->
    [*] Build static binary (no shared libs)

进行编译：

make -j$(nproc) && make install

制作内存根文件系统镜像：

cd rootfs
cp ../../busybox-1.31.1/_install/* ./ -rf
mkdir dev proc sys home
sudo cp -a /dev/{null,console,tty,tty1,tty2,tty3,tty4} dev/

 准备init脚本在/rootfs/init下：

#!/bin/sh
mount -t proc none /proc
mount -t sysfs none /sys
echo "Wellcome MajingnanOS!"
echo "--------------------"
cd home
/bin/sh

给init加上运行权限：

chmod +x init

打包成内存根文件系统镜像：

find . -print0 | cpio --null -ov --format=newc | gzip -9 > ../rootfs.cpio.gz

尝试启动内核：

qemu-system-aarch64 -m 128M -smp 1 -cpu cortex-a57 -machine virt -kernel arch/arm64/boot/Image -initrd rootfs.cpio.gz -append "rdinit=/init console=ttyAMA0 loglevel=8" -nographic -s

此时已经成功启动内核（由于使用的虚拟机的原因tty部分有点问题）：

二、使用内嵌汇编触发 time/gettimeofday 系统调用

接下来使用内嵌汇编触发 gettimeofday 的用户态，在rootfs目录下创建test.c文件，文件内容如下：

#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;
}

然后进行编译：

aarch64-linux-gnu-gcc -o test test.c -static

此时rootfs文件夹下就有test可执行文件了，然后用 ARM 环境下编译的 busybox 重新制作一个根文件系统，test 可执行文件就在虚拟机的根目录下了（不明白这句话就执行下面这行指令就可以啦hh~）。 

make ARCH=arm64 Image -j8  CROSS_COMPILE=aarch64-linux-gnu-

如果要在 VSCode 上调试，还需要更改 .vscode 目录下的 launch.json 和 tasks.json，参考配置如下。

launch.json文件如下：（注释掉的第一部分是第一次实验X86的配置）

// {
//     // 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",
//         "miDebuggerServerAddress": "localhost:1234",
//         "args": [],
//         "stopAtEntry": true,
//         "cwd": "${workspaceFolder}",
//         "environment": [],
//         "externalConsole": false,
//         "MIMode": "gdb",
//         "miDebuggerArgs": "-n",
//         "targetArchitecture": "x64",
//         "setupCommands": [
//           {
//             "text": "set arch i386:x86-64:intel",
//             "ignoreFailures": false
//           },
//           {
//             "text": "dir .",
//             "ignoreFailures": false
//           },
//           {
//             "text": "add-auto-load-safe-path ./",
//             "ignoreFailures": false
//           },
//           {
//             "text": "-enable-pretty-printing",
//             "ignoreFailures": true
//           }
//         ]
//       }
//     ]
//   }


// ARM
{
  // 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
        }
      ]
    }
  ]
}

 task.json文件如下：（注释掉的第一部分是第一次实验X86的配置）

// {
//     // 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-x86_64 -kernel ${workspaceFolder}/arch/x86/boot/bzImage -initrd rootfs.cpio.gz -S -s -nographic -append \"console=ttyS0\"",
//         "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"
//         }
//       }
//     ]
// }

// ARM
{
  // 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.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"
      }
    }
  ]
}

 在 VSCode 中启动调试。首先在窗口左下角的断点设置处新增断点 __arm64_sys_gettimeofday（32 位 ARM 下是 sys_gettimeofday，注意不要搞错了），再在终端中执行 test，可以看到调试器成功在对应的内核函数处停了下来。

 

三、分析 time/gettimeofday 系统调用的执行过程

1、分析系统调用

通过查看调用堆栈，我们能很容易地分析出 ARM64 下系统调用的执行过程。ARM64 架构下 Linux 系统调用由同步异常 svc 指令触发，当用户态（EL0 级）程序调用库函数 gettimeofday() 从而触发系统调用的时候，先把系统调用的参数依次放入 X0-X5 这 6 个寄存器（Linux 系统调用最多有 6 个参数，ARM64 函数调用参数可以使用 X0-X7 这 8 个寄存器），然后把系统调用号放在 X8 寄存器里，最后执行 svc 指令，CPU 即进入内核态（EL1 级）。本文使用内嵌汇编触发系统调用，我们也编写相应的汇编代码完成了上述过程。

svc指令一般会带一个立即数参数，一般是 0x0，但并没有被 Linux内核使用，而是把系统调用号放到了 X8寄存器里。

ARM64 架构的 CPU 中，Linux 系统调用（同步异常）和其他异常的处理过程大致相同。异常发生时，CPU 首先把异常的原因（比如执行 svc 指令触发系统调用）放在 ESR_EL1 寄存器里；把当前的处理器状态（PSTATE）放入 SPSR_EL1 寄存器里；把当前程序指针寄存器 PC 的值存入 ELR_EL1 寄存器里（保存断点），然后 CPU 通过异常向量表（vectors）基地址和异常的类型计算出异常处理程序的入口地址，即 VBAR_EL1 寄存器加上偏移量取得异常处理的入口地址，接着开始执行异常处理入口的第一行代码。这一过程是 CPU 硬件自动完成的，不需要程序干预。

2、中断处理分析（保存现场）

以 svc 指令对应的 el0_sync 为例，el0_sync 处的内核汇编代码首先做的就是保存异常发生时程序的执行现场（保存现场，即用户栈、通用寄存器等），然后根据异常发生的原因（ESR_EL1 寄存器中的内容）跳转到 el0_svc，el0_svc 会调用 el0_svc_handler、el0_svc_common 函数，将 X8 寄存器（regs->regs[8]）中存放的系统调用号传递给 invoke_syscall 函数。

总结一下：

el0_sync主要分为两部分：

第一部分实现从用户空间到内核空间的上下文切换： kernel_entry 0；

第二部是根据异常症状寄存器esr_el1判断异常原因，然后再进入具体处理函数。

系统调用是用户态执行SVC指令导致的，因此要进入el0_svc处理函数。

用户态发生的中断处理接口为el0_sync（内核态发生的中断处理接口是el1_sync）

查看el0_sync的代码：(arch/arm64/kernel/entry.S)

 

这里el0_sync首先执行kernel_entry 0，kernel_entry对应的代码（代码有点多...这里放上老师ppt里选出的关键代码：

	.macro	kernel_entry, el, regsize = 64
      ...
	stp	x0, x1, [sp, #16 * 0]
	stp	x2, x3, [sp, #16 * 1]
	...
	stp	x26, x27, [sp, #16 * 13]
	stp	x28, x29, [sp, #16 * 14]
      ...
	mrs	x21, sp_el0
	mrs	x22, elr_el1
	mrs	x23, spsr_el1
      stp	   	lr, x21, [sp, #S_LR]      // lr is x30
      stp		x22, x23, [sp, #S_PC]
      ...
	.endm

首先将通用寄存器x0~x29保存到当前进程的内核栈，然后是从SP_EL0、SPSR_EL1、ELR_EL1寄存器中读取用户栈栈顶地址、发生异常时的处理器状态和返回地址，将这三个值以及发生异常时的LR寄存器中的值都保存到当前进程的内核栈中以struct pt_regs结构体的格式保存在当前进程内核栈的栈底，这样就完成了硬件上下文的save过程。

3、内核堆栈pt_regs（保存现场）

保存现场的主要工作如上代码所示，是保存x0-x30及sp、pc和pstate，这和struct pt_regs数据结构的起始部分正好一一对应。

 pt_regs的结构：

struct pt_regs {
        union {
                struct user_pt_regs user_regs;
                struct {
                        u64 regs[31];
                        u64 sp;
                        u64 pc;
                        u64 pstate;
                };
        };
        ...
};

注：pt_regs是发生异常时保存的处理器现场，用于异常处理完后来恢复现场。

el0_sync在完成保存现场的工作之后，会根据ESR_EL1寄存器确定同步异常产生的原因，同步异常产生的原因很多，在ARM64 Linux中最常见的原因是svc指令触发了系统调用，所以排在最前面的就是条件判断跳转到el0_svc，el0_svc中主要负责调用C代码的el0_svc_handler处理系统调用和ret_to_user系统调用返回。

可以看到svc_handler又执行了svc_common，这里正好与前面我们gdb调试查看堆栈对应上了。 

 

 

接着执行 invoke_syscall 函数，将通用寄存器中的内容传入 syscall_fn()，引出系统调用内核处理函数 __arm64_sys_gettimeofday（32 位 ARM 下是 sys_gettimeofday）。  

老师的ppt上做了详细解释：从invoke_syscall函数中我们可以看到当系统调用号（scno）小于系统调用总个数（sc_nr）时，会找到系统调用号作为下标的syscall_table数组中的函数指针（syscall_fn）。注意这里syscall_table数组就是sys_call_table数组，只是实参和形参传递过程中改了个名字哦。然后通过__invoke_syscall函数执行该系统调用内核处理函数，即将__invoke_syscall函数的两个参数regs和syscall_fn变为调用syscall_fn(regs)，regs中存储着系统调用参数（regs->regs[0-5]）和系统调用号（regs->regs[8]），从而执行该系统调用内核处理函数。最后将系统系统调用内核处理函数的返回值保存到内核堆栈里保存x0的位置，以便将返回值在恢复现场系统调用返回时可以传递到用户态x0寄存器。

 

 

系统调用内核处理函数执行完成后，会将系统调用的返回值存放在 X0 寄存器中。 

 

4、中断处理分析（恢复现场 ） 

系统调用返回前，需要恢复异常发生时程序的执行现场（恢复现场），其中就包括恢复 ELR_EL1 和 SPSR_EL1 的值（原因是异常会发生嵌套，一旦发生异常嵌套 ELR_EL1 和 SPSR_EL1 的值就会随之发生改变）。最后内核调用异常返回指令 eret，CPU 硬件把 ELR_EL1 写回 PC，把 SPSR_EL1 写回 PSTATE，返回用户态继续执行用户态程序。如下图所示，该部分操作由 ret_to_user 函数中的 kernel_exit 0 完成。 

 

老师的ppt上做了详细的解释：从系统调用返回前会处理一些工作（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寄存器。