Linux操作系统分析_lab4：以time/gettimeofday系统调用为例分析ARM64 Linux 5.4.34

实验环境

Ubuntu 20.04.5 LTS 内核版本 5.4.34

环境配置

配置ARM64环境：

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

进行如下修改：


关闭KASLR，否则会导致调试的时候打断点失败

编译内核

编译arm64内核前需要export交叉编译选项，然后编译arm64内核

export ARCH=arm64
export CROSS_COMPILE=aarch64-linux-gnu-
make Image -j$(nproc) 

制作内存根文件系统

编译busybox之前也需要export交叉编译选项

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

然后配置编译选项，进行如下修改

make menuconfig

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

进行编译

make -j$(nproc) && make install

配置根文件系统

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

在rootfs目录下准备init脚本，内容如下

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

给init脚本添加可执行权限

chmod +x init

将rootfs目录打包成内存根文件系统镜像

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

测试挂载根文件系统，看内核启动完成后是否执行init脚本

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

启动成功

触发系统调用

使用内嵌汇编触发 gettimeofday 的用户态，在rootfs/home目录下创建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

重新制作根文件系统镜像，重新启动qemu查看home目录如下

修改vscode的tasks.json和launch.json文件如下：

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

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

在vscode中打断点进行分析

启动调试，然后在终端执行test.c，可以看到程序停在了断点处

分析系统调用

ARM64 Linux系统调用的执行过程如下

在vscode查看堆栈情况如图

用户态程序执行svc指令，CPU会把当前程序指针寄存器PC放入ELR_EL1寄存器里，把PSTATE放入SPSR_EL1寄存器里，把异常产生的原因（这里是调用了svc指令触发系统调用）放在ESR_EL1寄存器里。这时CPU是知道异常类型和异常向量表的起始地址的，所以可以自动把VBAR_EL1寄存器的值（vectors），和第3组Synchronous的偏移量0x400相加，即vectors + 0x400，得出该异常向量空间的入口地址，然后跳转到那里执行异常向量空间里面的指令。
每个异常向量空间仅有128个字节，最多可以存储32条指令（每条指令4字节），而且异常向量空间最后一条指令是b指令，对于系统调用来说会跳转到el0_sync，这样就从异常向量空间跳转同步异常处理程序的入口。

保存现场

在ARM64架构下Linux系统调用由同步异常svc指令触发。当用户态（EL0级）程序调用库函数gettimeofday()从而触发系统调用的时候，先把系统调用的参数依次放入X0-X5这6个寄存器（Linux系统调用最多有6个参数，ARM64函数调用参数可以使用X0-X7这8个寄存器），然后把系统调用号放在X8寄存器里，最后执行svc指令，CPU即进入内核态（EL1级）。

进入异常处理入口之后，以svc指令对应的el0_sync为例，el0_sync处的内核汇编代码首先做的就是保存异常发生时程序的执行现场（保存现场），然后根据异常发生的原因（ESR_EL1寄存器）跳转到el0_svc，el0_svc中主要负责调用C代码的el0_svc_handler处理系统调用和ret_to_user系统调用返回。

可以看到svc_handler()又调用了el0_svc_common()

从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寄存器。

恢复现场

从系统调用返回前会处理一些工作（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寄存器。