最新 x86_64 系统调用入口分析 (基于5.7.0)

整体概览

最近的工作涉及系统调用入口,但网上的一些分析都比较老了,这里把自己的分析过程记录一下,仅供参考。

x86_64位系统调用使用 SYSCALL 指令进入内核空间,使CPU切换到ring 0。SYSCALL 指令主要工作为从MSR寄存器加载CS/SS,以及系统调用入口(entry_SYSCALL_64),从而进入系统调用处理流程。

MSR寄存器相关这里不再介绍,需要相关知识的指路 寄存器总结 以及

Model-specific register

SYSCALL 指令

  1. IF (CS.L 1 ) or (IA32_EFER.LMA 1) or (IA32_EFER.SCE 1)
  2. (* Not in 64-Bit Mode or SYSCALL/SYSRET not enabled in IA32_EFER *)
  3. THEN #UD;
  4. FI;
  5. RCX RIP; (* Will contain address of next instruction *)
  6. RIP IA32_LSTAR;
  7. R11 RFLAGS;
  8. RFLAGS RFLAGS AND NOT(IA32_FMASK);
  9. CS.Selector IA32_STAR[47:32] AND FFFCH (* Operating system provides CS; RPL forced to 0 *)
  10. (* Set rest of CS to a fixed value *)
  11. CS.Base 0;
  12. (* Flat segment *)
  13. CS.Limit FFFFFH;
  14. (* With 4-KByte granularity, implies a 4-GByte limit *)
  15. CS.Type 11;
  16. (* Execute/read code, accessed *)
  17. CS.S 1;
  18. CS.DPL 0;
  19. CS.P 1;
  20. CS.L 1;
  21. (* Entry is to 64-bit mode *)
  22. CS.D 0;
  23. (* Required if CS.L = 1 *)
  24. CS.G 1;
  25. (* 4-KByte granularity *)
  26. CPL 0;
  27. SS.Selector IA32_STAR[47:32] + 8;
  28. (* SS just above CS *)
  29. (* Set rest of SS to a fixed value *)
  30. SS.Base 0;
  31. (* Flat segment *)
  32. SS.Limit FFFFFH;
  33. (* With 4-KByte granularity, implies a 4-GByte limit *)
  34. SS.Type 3;
  35. (* Read/write data, accessed *)
  36. SS.S 1;
  37. SS.DPL 0;
  38. SS.P 1;
  39. SS.B 1;
  40. (* 32-bit stack segment *)
  41. SS.G 1;
  42. (* 4-KByte granularity *)
  43. (代码引自 https://www.felixcloutier.com/x86/syscall)

这里主要做了三个工作:

  • 将RIP保存到RCX寄存器,即将SYSCALL指令下一条指令地址保存到RCX,后续用到。
  • 从 IA32_LSTAR MSR 寄存器加载系统调用入口地址。64 位寄存器名为MSR_LSTAR。
  • 从 IA32_STAR MSR 寄存器47-32到加载CS/SS段。64 位寄存器名为 MSR_STAR,其在内核启动过程中初始化。

MSR寄存器初始化源码点这

核心为:

  1. wrmsr(MSR_STAR, 0, (__USER32_CS << 16) | __KERNEL_CS);
  2. wrmsrl(MSR_LSTAR, (unsigned long)entry_SYSCALL_64);

入口地址

接下来就是进入 entry_SYSCALL_64处理流程,源码在这

但是这里有一个问题:在较新版内核中,都已支持 PTI 机制,用户态与内核态使用不同页表,而这里 entry_SYSCALL_64 已经属于内核代码,而我们仔细观察entry_SYSCALL_64 实现,在第四行才切换内核页表。想要 entry_SYSCALL_64 能被执行,就需要 cpu_entry_area 的作用了。

  1. SYM_CODE_START(entry_SYSCALL_64)
  2. UNWIND_HINT_EMPTY
  3. /* * Interrupts are off on entry. * We do not frame this tiny irq-off block with TRACE_IRQS_OFF/ON, * it is too small to ever cause noticeable irq latency. */
  4. swapgs
  5. /* tss.sp2 is scratch space. */
  6. movq %rsp, PER_CPU_VAR(cpu_tss_rw + TSS_sp2)
  7. SWITCH_TO_KERNEL_CR3 scratch_reg=%rsp

cpu_entry_area 包括了CPU进入内核需要的所有数据/代码,会被映射到用户态页表。了解点着,但是要注意较新版本cpu_entry_area已经不包含其中的 a set of trampolines;至于为什么看这

那又是怎么实现?

翻来覆去,终于在 pti 初始化处找到了关键点,其实现为

  1. /* * Clone the populated PMDs of the entry and irqentry text and force it RO. */
  2. static void pti_clone_entry_text(void){
  3. pti_clone_pgtable((unsigned long) __entry_text_start,
  4. (unsigned long) __irqentry_text_end,
  5. PTI_CLONE_PMD);}

其将 __entry_text_start 开头的地址复制,而这又与 entry_SYSCALL_64 有什么关系?我们继续往下找

  1. #define ENTRY_TEXT \
  2. ALIGN_FUNCTION(); \
  3. __entry_text_start = .; \
  4. *(.entry.text) \
  5. __entry_text_end = .;

而再看 entry_SYSCALL_64 定义的文件头部

  1. .code64
  2. .section .entry.text, "ax"

所以这里就会把 entry_SYSCALL_64 等一众函数地址拷贝到用户页表,从而实现可访问。具体定义展开这里就不进行了。

继续执行

回到 entry_SYSCALL_64,我们跳过一系列处理,可以看到一个关键点

  1. call do_syscall_64

很显然了,接下来就是执行 do_syscall_64 了。后面就是常规操作了。

最新 x86_64 系统调用入口分析 (基于 5.7.0)的更多相关文章

  1. springmvc工作原理以及源码分析(基于spring3.1.0)

    springmvc是一个基于spring的web框架.本篇文章对它的工作原理以及源码进行深入分析. 一.springmvc请求处理流程 二.springmvc的工作机制 三.springmvc核心源码 ...

  2. 开源GUI-Microwindows之程序入口分析

    **************************************************************************************************** ...

  3. Android 短信模块分析(三) MMS入口分析

    MMS入口分析:      在Mms中最重要的两个Activity,一个是conversationList(短信列表) ,另一个就是ComposeMessageActivity(单个对话或者短信).每 ...

  4. 分析Linux内核5.0系统调用处理过程

    学号: 363 本实验来源 https://github.com/mengning/linuxkernel/ 一.实验要求 1.编译内核5.02.qemu -kernel linux-5.0.1/ar ...

  5. Socket与系统调用深度分析

    学习一下对Socket与系统调用的分析分析 一.介绍 我们都知道高级语言的网络编程最终的实现都是调用了系统的Socket API编程接口,在操作系统提供的socket系统接口之上可以建立不同端口之间的 ...

  6. Spring IoC 源码分析 (基于注解) 之 包扫描

    在上篇文章Spring IoC 源码分析 (基于注解) 一我们分析到,我们通过AnnotationConfigApplicationContext类传入一个包路径启动Spring之后,会首先初始化包扫 ...

  7. ceph-csi源码分析(3)-rbd driver-服务入口分析

    更多ceph-csi其他源码分析,请查看下面这篇博文:kubernetes ceph-csi分析目录导航 ceph-csi源码分析(3)-rbd driver-服务入口分析 当ceph-csi组件启动 ...

  8. Spring Ioc源码分析系列--Ioc源码入口分析

    Spring Ioc源码分析系列--Ioc源码入口分析 本系列文章代码基于Spring Framework 5.2.x 前言 上一篇文章Spring Ioc源码分析系列--Ioc的基础知识准备介绍了I ...

  9. AtomicInteger源码分析——基于CAS的乐观锁实现

    AtomicInteger源码分析——基于CAS的乐观锁实现 1. 悲观锁与乐观锁 我们都知道,cpu是时分复用的,也就是把cpu的时间片,分配给不同的thread/process轮流执行,时间片与时 ...

随机推荐

  1. 通常一个 Xml 映射文件,都会写一个 Dao 接口与之对应, 请问,这个 Dao 接口的工作原理是什么?Dao 接口里的方法, 参数不同时,方法能重载吗?

    Dao 接口即 Mapper 接口.接口的全限名,就是映射文件中的 namespace 的值: 接口的方法名,就是映射文件中 Mapper 的 Statement 的 id 值:接口方法内的 参数,就 ...

  2. XMLBeanFactory?

    最常用的就是org.springframework.beans.factory.xml.XmlBeanFactory ,它根据XML文件中的定义加载beans.该容器从XML 文件读取配置元数据并用它 ...

  3. CommonsCollection3

    CommonsCollection3 1.前置知识 CommonsCollection3其实就是cc1和cc2的组合,不用再学那么多知识了,再学习另两个生面孔类 1.1.InstantiateTran ...

  4. 51单片机头文件reg51.h详解

    转自:http://www.51hei.com/mcu/2670.html 我们在用c语言编程时往往第一行就是头文件,51单片机为reg51.h或reg52.h,51单片机相对来说比较简单,头文件里面 ...

  5. RESTful API/Web API

    Microsoft REST API Guidelines Are Not RESTful White House Web API Standards Microsoft REST API Guide ...

  6. 使用Google Closure Compiler高级压缩Javascript代码

    背景 前端开发中,特别是移动端,Javascript代码压缩已经成为上线必备条件. 如今主流的Js代码压缩工具主要有: 1)Uglify http://lisperator.net/uglifyjs/ ...

  7. 【c++】容器的基本操作

    操作\容器 vector list string set stack queue map 插入 push_bcak().insert() push_back() .push_front().inser ...

  8. ruby 版本管理RVM (ruby version manager)

    macOS. 自带的ruby 版本目录权限比较高, 经常有很多 操作需要权限而不能执行 虽然 macOS 自带了一个 ruby 环境,但是是系统自己使用的,所以权限很小,只有 system. 而/Li ...

  9. 使用 LOAD DATA LOCAL INFILE,sysbench 导数速度提升30%

    1. LOAD DATA INFILE 为什么比 INSERT 快? 2. sysbench 压测 MySQL 的四个标准步骤. 3. 怎么让 sysbench 支持 LOAD DATA LOCAL ...

  10. springcloud集群测试

    使用ribbon实现负载均衡,访问同一个url,轮询不同的服务提供端,从不同的数据库中取数据.