Adrian's Space

Linux系统调用：用户态陷入内核完整流程

10分钟阅读

1 Linux系统调用：用户态陷入内核完整流程

本文将彻底讲透 Linux 系统调用的本质，从你最初的疑问出发，理清系统调用和 ioctl 的关系，再一步步拆解用户态陷入内核、与内核交互的完整过程。

1.1 一、先理清核心误区：系统调用和 ioctl 的关系

你之前的疑问：系统调用是不是本质上就是字符设备的 ioctl？

答案是：完全搞反了。

  1. ioctl 本身就是一个系统调用：它是 Linux 众多系统调用里的普通一员，和read、write、fork是平级的。

  2. 字符设备的 ioctl，只是 ioctl 的一个应用场景：当你写自定义内核模块时，为了不用修改内核、不用新增系统调用，你会注册一个字符设备，然后用ioctl这个系统调用，给用户态提供自定义的控制接口。

  3. 系统调用是基础，ioctl 是它的子集：所有的 ioctl 操作，最终都要通过系统调用的机制才能陷入内核，而不是反过来。

1.2 二、基础前提：CPU 的特权级隔离

为什么用户态不能直接调用内核的函数？这是 CPU 硬件层面的保护机制：

x86 架构下，CPU 定义了 4 个特权级（Ring 0~Ring 3）：

  • 内核态 = Ring 0：最高权限，可以访问所有内存、操作所有硬件、执行所有 CPU 指令。

  • 用户态 = Ring 3：最低权限，只能访问当前进程的用户内存，不能碰内核内存，不能直接操作硬件。

所以你根本不能直接调用内核里的sys_read这种函数 —— 你用户态的代码没有权限访问内核的代码段，直接调用会触发 CPU 的权限错误，直接崩溃。

系统调用就是 CPU 给用户态开的唯一合法的 “后门”，让你可以安全地请求内核帮你干活。

1.3 三、完整流程：以read(0, buf, 100)为例

我们以最常用的read系统调用为例，一步步拆解整个过程，每一步做了什么都讲透：

1.3.1 第一步：用户态准备参数，触发陷入指令

当你在用户态写read(0, buf, 100)，你调用的其实是 libc 库里的封装函数，它会帮你做这些准备工作：

  1. 把系统调用号放到寄存器：每个系统调用有唯一的编号，read的编号是 0，把它放到rax寄存器。

  2. 把参数放到指定寄存器：64 位系统下，系统调用的前 6 个参数会依次放到rdi、rsi、rdx、r10、r8、r9 寄存器。 所以这里：

    • rdi = 0（fd，文件描述符）

    • rsi = buf（用户态的缓冲区指针）

    • rdx = 100（要读的长度）

  3. 执行syscall指令：这是 CPU 提供的快速陷入指令，告诉 CPU：“我要进内核了！”

老的 32 位系统用的是int 0x80软中断，原理完全一样，就是速度慢一些，现在 64 位系统都用更快的syscall指令了。

1.3.2 第二步：CPU 硬件自动切换到内核态

当 CPU 执行syscall指令，这一步是硬件自动完成的，不需要内核代码干预，瞬间做完：

  1. 切换特权级：把 CPU 从 Ring 3（用户态）切到 Ring 0（内核态），现在获得了访问内核内存的权限。

  2. 切换栈：从当前进程的用户栈，切换到这个进程独立的内核栈（每个进程都有自己的内核栈，用来存内核态的调用栈，互不干扰）。

  3. 保存用户态现场：把用户态的寄存器（比如 RIP、RFLAGS、用户栈指针 RSP）自动保存到内核栈里，方便之后返回的时候恢复。

  4. 跳转到内核入口：CPU 根据预设的地址，跳转到内核里的系统调用入口函数entry_SYSCALL_64（这是内核里写死的唯一入口，所有系统调用都从这进）。

这一步做完，你就已经完全进入内核了，现在执行的是内核的代码了。

1.3.3 第三步：内核分发系统调用，执行处理函数

内核的入口函数entry_SYSCALL_64开始干活：

  1. 拿到系统调用号：从rax寄存器拿到你之前存的系统调用号（这里是 0，代表read）。

  2. 查系统调用表：内核里有一张全局的sys_call_table，每个系统调用号对应一个内核处理函数的地址：

    sys_call_table[0] = sys_read    // read的处理函数
sys_call_table[1] = sys_write   // write的处理函数
sys_call_table[16] = sys_ioctl  // ioctl的处理函数
sys_call_table[57] = sys_fork   // fork的处理函数
...

    所以这里查到sys_read这个函数的地址。

  3. 安全检查：内核会先检查你传入的参数合不合法，防止你搞破坏：

    • 比如你传入的buf指针，是不是真的属于用户态的地址？防止你传一个内核的地址，让内核把敏感数据读到你这里。

    • 比如 fd=0 是不是你真的打开的文件？你有没有权限读这个文件？

  4. 执行内核处理函数：调用sys_read(fd, buf, count)，这时候内核就开始真正干活了：

    • 找到你要读的文件的 inode

    • 调用磁盘驱动，从磁盘读数据

    • 把读到的数据拷贝到你用户态的buf里（内核态可以直接访问用户态的内存）

    • 执行完，把返回值（读到的字节数，或者负数错误码）放到rax寄存器里。

1.3.4 第四步：返回用户态，恢复现场

内核处理完，执行sysret指令，CPU 又自动做切换：

  1. 恢复用户态现场：把之前保存在内核栈里的用户态寄存器（RIP、RSP、RFLAGS）全部恢复。

  2. 切换栈：从内核栈切回用户栈。

  3. 切换特权级：从 Ring 0 切回 Ring 3，回到用户态的权限。

  4. 回到用户态代码：跳回到你用户态调用syscall的下一条指令，继续执行。

这个时候，你用户态的代码就拿到了rax里的返回值，libc 会把它包装一下：如果是负数错误，就把它转成errno，然后返回给你。

1.4 四、关键细节你必须知道

  1. 所有系统调用都是同一个入口：不管是read、write、fork还是ioctl，都是通过syscall指令陷入内核，然后根据系统调用号区分要执行哪个函数。

  2. 内核可以直接访问用户内存：内核态有最高权限，所以可以直接读写用户态的内存，比如read把数据直接拷贝到你用户的 buf 里，不需要额外的拷贝（当然会做安全检查）。

  3. 每个进程的内核栈是独立的：所以不同进程的系统调用不会互相干扰，就算一个进程的系统调用出错了，也不会影响其他进程。

  4. 系统调用的开销：整个过程的开销主要是特权级切换、保存恢复寄存器，单次其实很小（几十纳秒），但如果你频繁调用小的系统调用，比如百万次read，这个开销就会累积，所以才有io_uring这种技术，减少系统调用的次数。

  5. 参数的拷贝：对于用户态的指针参数，比如open的路径字符串，内核会把它拷贝到内核的内存里，防止你在系统调用执行的过程中修改这个字符串，导致内核读到错误的数据。

1.5 一句话总结

系统调用的本质就是： 用户态通过 CPU 提供的syscall指令，合法地陷入内核，告诉内核我要调用哪个服务，内核帮你干完活，再切回用户态把结果给你。 整个过程是硬件和内核配合完成的，ioctl 只是众多系统调用里的一个而已。

关系图谱

反向链接