系统调用是如何实现的

系统 Linux
在执行 entry_SYSCALL_64 函数时,内核代码会根据约定,先从rax寄存器中获取想要执行的系统调用的编号,然后根据该编号从sys_call_table数组中找到对应的系统调用函数。

[[379322]]

 

这张图画了挺久的,主要是想让大家可以从全局角度,看下linux内核中系统调用的实现。

因为图片比较大,微信公众号上压缩的比较厉害,所以很多细节都看不清了,我单独传了一份到github上,想要原版图片的,可以点击下方的阅读原文直接访问github,或者也可以加我微信 yt0x01,我单独发给你。

在讲具体的细节之前,我们先根据上图,从整体上看一下系统调用的实现。

系统调用的实现基础,其实就是两条汇编指令,分别是syscall和sysret。

syscall使执行逻辑从用户态切换到内核态,在进入到内核态之后,cpu会从 MSR_LSTAR 寄存器中,获取处理系统调用内核代码的起始地址,即上面的 entry_SYSCALL_64。

在执行 entry_SYSCALL_64 函数时,内核代码会根据约定,先从rax寄存器中获取想要执行的系统调用的编号,然后根据该编号从sys_call_table数组中找到对应的系统调用函数。

接着,从 rdi, rsi, rdx, r10, r8, r9 寄存器中获取该系统调用函数所需的参数,然后调用该函数,把这些参数传入其中。

在系统调用函数执行完毕之后,执行结果会被放到rax寄存器中。

最后,执行sysret汇编指令,从内核态切换回用户态,用户程序继续执行。

如果用户程序需要该系统调用的返回结果,则从rax中获取。

总体流程就是这样,相对来说,还是比较简单的,主要就是先去理解syscall和sysret这两条汇编指令,在理解这两条汇编指令的基础上,再去看内核源码,就会容易很多。

有关syscall和sysret指令的详细介绍,请参考Intel® 64 and IA-32 Architectures Software Developer’s Manual。

有了上面对系统调用的整理理解,我们接下来看下其具体的实现细节。

以write系统调用为例,其对应的内核源码为:

 

在内核中,所有的系统调用函数都是通过 SYSCALL_DEFINE 等宏定义的,比如上面的write函数,使用的是 SYSCALL_DEFINE3。

将该宏展开后,我们可以得到如下的函数定义:

 

由上可见,SYSCALL_DEFINE3宏展开后为三个函数,其中只有__x64_sys_write是外部可访问的,其它两个都有被static修饰,不能被外部访问,所以注册到上文中提到的sys_call_table数组里的函数,应该就是这个函数。

那该函数是怎么注册到这个数组的呢?

我们先不说答案,先来看下sys_call_table数组的定义:

 

由上可见,该数组各元素的默认值都是 __x64_sys_ni_syscall:

 

该函数也非常简单,就是直接返回错误码 -ENOSYS,表示系统调用非法。

sys_call_table数组定义的地方好像只设置了默认值,并没有设置真正的系统调用函数。

我们再看看其他地方,看是否有代码会注册真正的系统调用函数到sys_call_table数组里。

可惜,并没有。

这就奇怪了,那各系统调用函数到底是在哪里注册的呢?

我们再回头仔细看下sys_call_table数组的定义,它在设置完默认值之后,后面还include了一个名为asm/syscalls_64.h的头文件,这个位置include头文件还是比较奇怪的,我们看下它里面是什么内容。

但是,这个文件居然不存在。

那我们只能初步怀疑这个头文件是编译时生成的,带着这个疑问,我们去搜索相关内容,确实发现了一些线索:

 

这个文件确实是编译时生成的,上面的makefile中使用了syscalltbl.sh脚本和syscall_64.tbl模板文件来生成这个syscalls_64.h头文件。

我们来看下syscall_64.tbl模板文件的内容:

 

这里确实定义了write系统调用,且标明了它的编号是1。

我们再来看下生成的syscalls_64.h头文件:

 

这里面定义了很多好像宏调用一样的东西。

__SYSCALL_COMMON,这个不就是sys_call_table数组定义那里define的那个宏嘛。

再去上面看下__SYSCALL_COMMON这个宏定义,它的作用是将sym表示的函数赋值到sys_call_table数组的nr下标处。

所以对于__SYSCALL_COMMON(1, sys_write)来说,它就是注册__x64_sys_write函数到sys_call_table数组下标为1的槽位处。

而这个__x64_sys_write函数,正是我们上面猜测的,SYSCALL_DEFINE3定义的write系统调用,展开之后的一个外部可访问的函数。

这样就豁然开朗了,原来真正的系统调用函数的注册,是通过先定义__SYSCALL_COMMON宏,再include那个根据syscall_64.tbl模板生成的syscalls_64.h头文件来完成的,非常巧妙。

系统调用函数注册到sys_call_table数组的过程,到这里已经非常清楚了。

下面我们继续来看下哪里在使用这个数组:

 

do_syscall_64在使用,方式是先通过nr在sys_call_table数组中找到对应的系统调用函数,然后再调用该函数,将regs传入其中。

这个流程和我们上面预估的一样,且传入的regs参数类型,和我们上面注册的系统调用函数所需的类型也一样。

那也就是说,regs参数的字段里,是带着各系统调用函数所需的参数的,SYSCALL_DEFINE等宏展开出来的一系列函数,会从这些字段中提取出真正的参数,然后对其进行类型转换,最后这些参数被传入到最终的系统调用函数中。

对于上面的write系统调用宏展开后的那些函数,__x64_sys_write会先从regs中提取出di, si, dx字段作为真正参数,然后__se_sys_write会将这些参数转成正确的类型,最后__do_sys_write函数被调用,转换后的这些参数被传入其中。

在系统调用函数执行完毕后,其结果会被赋值到了regs的ax字段里。

由上可见,系统调用函数的参数及返回值的传递,都是通过regs来完成的。

但文章开始的时候不是说,系统调用的参数及返回值的传递,是通过寄存器来完成的吗,这里怎么是通过struct pt_regs的字段呢?

先别急,先来看下struct pt_regs的定义:

 

你有没有发现,这里面的字段名都是寄存器的名字。

那是不是说,在执行系统调用的代码里,有逻辑把各寄存器里的值放到了这个结构体的对应字段里,在结束系统调用时,这些字段里的值又被赋值到各个对应的寄存器里呢?

离真相越来越近。

我们继续看使用了do_syscall_64的地方:

 

上图中的entry_SYSCALL_64方法,就是系统调用流程中最重要的一个方法了,为了便于理解,我对该方法做了很多修改,并添加了很多注释。

这里需要注意的是100行到121行这段逻辑,它将各寄存器的值压入到栈中,以此来构建struct pt_regs对象。

这就能构建出一个struct pt_regs对象了?

是的。

我们回上面看下struct pt_regs的定义,看其字段名字及顺序是不是和这里的压栈顺序正好相反。

我们再想下,当我们要构建一个struct pt_regs对象时,我们要为其在内存中分配一块空间,然后用一个地址来指向这段空间,这个地址就是该struct pt_regs对象的指针,这里需要注意的是,这个指针里存放的地址,是这段内存空间的最小地址。

再看上面的压栈过程,每一次压栈操作我们都可以认为是在分配内存空间并赋值,当r15被最终压入到栈中后,整个内存空间分配完毕,且数据也初始化完毕,此时,rsp指向的栈顶地址,就是这段内存空间的最小地址,因为压栈过程中,栈顶的地址是一直在变小的。

综上可知,在压栈完毕后,rsp里的地址就是一个struct pt_regs对象的地址,即该对象的指针。

在构建完struct pt_regs对象后,123行将rax中存放的系统调用编号赋值到了rdx里,124行将rsp里存放的struct pt_regs对象的地址,即该对象的指针,赋值到了rsi中,接着后面执行了call指令,来调用do_syscall_64方法。

调用do_syscall_64方法之前,对rdi和rsi的赋值,是为了遵守c calling convention,因为在该calling convention中约定,在调用c方法时,第一个参数要放到rdi里,第二个参数要放到rsi里。

我们再去上面看下do_syscall_64方法的定义,参数类型及顺序是不是和我们这里说的是完全一样的。

在调用完do_syscall_64方法后,系统调用的整个流程基本上就快结束了,上图中的129行到133行做的都是一些寄存器恢复的工作,比如从栈中弹出对应的值到rax,rip,rsp等等。

这里需要注意的是,栈中rax的值是在上面do_syscall_64方法里设置的,其存放的是系统调用的最终结果。

另外,在栈中弹出的rip和rsp的值,分别是用户态程序的后续指令地址及其堆栈地址。

最后执行sysret,从内核态切换回用户态,继续执行syscall后面逻辑。

到这里,完整的系统调用处理流程就已经差不多说完了,不过这里还差一小步,就是syscall指令在进入到内核态之后,是如何找到entry_SYSCALL_64方法的:

 

它其实是注册到了MSR_LSTAR寄存器里了,syscall指令在进入到内核态之后,会直接从这个寄存器里拿系统调用处理函数的地址,并开始执行。

系统调用内核态的逻辑处理就是这些。

下面我们用一个例子来演示下用户态部分:

 

编译并执行:

 

我们用syscall来执行write系统调用,写的字符串为Hi\n,syscall执行完毕后,我们直接使用ret指令将write的返回结果当作程序的退出码返回。

所以在上图中,输出了Hi,且程序的退出码是3。

如果对上面的汇编不太理解,可以把它想像成下面这个样子:

 

在这里,我们使用的是glibc中的write方法来执行该系统调用,其实该方法就是对syscall指令做的一层封装,本质上使用的还是我们上面的汇编代码。

这个例子到这里就结束了。

有没有觉得不太尽兴?

我们分析了这么多的代码,最终就用了这么个小例子就结束了,不行,我们要再做点什么。

要不我们来自己写个系统调用?

说干就干。

我们先在write系统调用下面定义一个我们自己的系统调用:

 

该方法很简单,就是将参数加10,然后返回。

再把这个系统调用在syscall_64.tbl里注册一下,编号为442:

 

编译内核,等待执行。

我们再把上面写的那个hi程序改下并编译好:

 

然后在虚拟机中启动新编译的linux内核,并执行上面的程序:

 

 

看结果,正好就是20。

 

搞定,收工。

本文转载自微信公众号「卯时卯刻」,可以通过以下二维码关注。转载本文请联系卯时卯刻公众号。

 

责任编辑:武晓燕 来源: 卯时卯刻
相关推荐

2022-08-17 08:10:34

语言VisitorListener

2009-10-23 09:38:59

VB.NET平台调用

2021-06-03 08:03:13

网络

2010-03-12 14:38:55

2010-01-26 14:04:14

C++Builder

2023-12-14 12:56:00

链式调用代码

2010-01-28 10:06:05

Linux系统调用

2022-04-02 07:52:47

DubboRPC调用动态代理

2022-03-14 15:26:59

Hi3516Ark子系统鸿蒙

2022-03-29 09:00:00

Angular框架REST API

2020-11-18 19:11:26

iOSFlutterNative

2017-01-11 09:22:03

大数据应用资源

2016-11-28 15:17:52

大数据应用大数据

2022-09-02 08:23:12

软件开发解耦架构

2009-07-07 16:38:36

ServletCont

2011-09-08 17:50:34

Windows7放大镜

2020-06-15 10:45:49

云计算自治系统冠状病毒

2010-08-25 10:18:27

2014-07-22 10:42:04

2012-05-28 20:54:36

Windows PhoMetro移动开发
点赞
收藏

51CTO技术栈公众号