【无标题】

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

1.搭建环境

使用的ubantu是x86架构，先安装交叉工具编译链

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

制作根文件系统
编译busybox

wget  https://busybox.net/downloads/busybox-1.33.1.tar.bz2
tar -xjf busybox-1.33.1.tar.bz2
cd busybox-1.33.1

打开静态库编译选项

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

指定编译工具

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

编译

make
make install

编译完成，在busybox目录下生成_install目录

2.触发系统调用

编写用户态触发系统调用

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

在arm64的time系统调用对应的内核函数打断点

下载并启动qemu

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-system-aarch64 -m 512M -smp 4 -cpu cortex-a57 -machine virt -kernel arch/arm64/boot/Image -append "rdinit=/linuxrc nokaslr console=ttyAMA0 loglevel=8" -nographic 

输入./test来运行之前写好的test触发系统调用：

./test

3.分析系统调用

用户态程序执行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，这样就从异常向量空间跳转同步异常处理程序的入口。

中断处理分析

el0_sync主要分为两部分：
第一部分实现从用户空间到内核空间的上下文切换： kernel_entry 0；
第二部是根据异常症状寄存器esr_el1判断异常原因，然后再进入具体处理函数。
系统调用是用户态执行SVC指令导致的，因此要进入el0_svc处理函数。
查看el0_sync的代码：

这里el0_sync首先执行kernel_entry 0，kernel_entry对应的代码：

.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

内核堆栈pt_regs

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

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