深入浅出Linux内核(内存篇):页表映射分段
- 2026-10-11 08:23:16
大家好，我是蟹老板~本文基于Linux5.6.4版本
但画饼归画饼，虚拟内存再花哨，数据终究是需要被实打实地写进物理内存里的。
所以怎么把那个虚拟地址（VA）巧妙地转换成物理地址（PA）？
这就是整个机制里最骚的操作了——地址转换。
大家瞅下面这张图。
进程1和进程2，都有自己完整的虚拟地址空间，而且都分用户空间和内核空间。这里有个容易搞混的点，记好了：不管哪个进程，面对的都是同一个内核，所以它们内核空间的VA K地址，最终都映射到物理内存的同一个PA K上。但用户空间就不一样了，哪怕俩进程的虚拟地址长得一样（比如都是0x12345678），映射到的物理地址也是完全不同的，不然进程间的数据不就串了？
这个从VA到PA的转换过程，行话就叫地址转换。
光靠软件做地址转换不现实，效率能低到你怀疑人生，还得靠硬件帮忙——就是内存管理单元（MMU），这玩意儿相当于地址转换的“专属工具人”：
| 要求 | 说明 |
|---|---|
| 特权模式 | 区分内核空间和用户空间，用户进程没法直接碰内核地址，碰了就报错 |
| 基址/界限寄存器 | 记着地址转换的基址，帮着找到地址映射表，相当于“地图索引” |
| 地址转换 | 核心活儿，把虚拟地址转换成物理地址，缺一不可 |
| 检查越界 | 转换地址的时候，顺便检查是不是越权访问了，比如用户态碰内核态的地址 |
| 基址/界限寄存器特权操作指令 | 只有内核能改这俩寄存器，保证每个进程的映射表不一样，不然映射就乱套了 |
| 触发异常 | 越权、越界的时候，会触发异常通知操作系统，不然程序就崩得不明不白 |
| 异常处理特权操作指令 | 操作系统处理内存访问异常的入口，相当于“急救通道” |
有了MMU硬件助力，操作系统的内存管理直接起飞。
用户和内核的环境隔离，靠特权模式把资源分层管着。用户态程序想直接操作内核的数据？门儿都没有！非得走系统调用、硬件中断这些合法路子，才能进高权限状态。
逻辑地址到物理地址的映射，MMU会用基址/界限寄存器里的页目录起始地址，再结合当前指令的逻辑地址，在硬件层面完成转换，比软件转换快多了。
多任务环境下，每个进程的虚存都是独立的，这也是MMU的功劳。进程切换的时候，操作系统会更新段基址和范围，MMU就能准确加载对应进程的页转换表，不会搞混。
还有个延迟分配物理内存的策略，特别实用。程序声明了一块内存，但还没实际用的时候，系统不会立马分配物理内存，也不建立页映射。等程序真要访问这块内存了，触发缺页中断，系统再动态分配——这样能省不少内存，不然好多声明了不用的内存就浪费了。对了，页属性里还有各种异常检测，比如访问权限不够、越界，都能及时发现，提升系统安全性。
咱们今天重点说的，就是MMU的核心机制之一——基于分页原理实现逻辑地址与实体内存之间的动态映射关系。
一、分段
用户进程的虚拟地址空间，其实是被拆成了好几个功能区的，不是一整块混沌的空间：
指令区和数据区是基础，指令区存程序的核心逻辑，数据区存全局变量、静态变量这些常驻数据。程序加载到内存的时候，内核会先把这俩区域的页表项配好，物理内存也分配好，不用咱们操心。
栈区就简单了，存程序运行时的临时数据，比如函数调用的参数、局部变量，用完就释放。
mmap映射区，主要靠mmap系统调用，实现page cache或者匿名内存页的映射，比如咱们读大文件的时候，就常用到这个。
堆空间，就是咱们用malloc、new动态分配内存的地方，也是最容易出bug的地方，比如内存泄漏、越界，我当年不知因为这玩意儿改了多少bug。
看下图，清楚了解下这些区域的分布：
正因为进程地址空间是这么划分的，MMU才采用了分段管理的架构。一个段，就是地址空间里连续、等长的一块，一般分成代码段、栈段、堆段三类。
分段的好处很明显，系统能给每个段分配不同的物理内存位置，灵活得很。
但要实现分段，MMU还得额外具备一些能力，不然玩不转：
| 要求 | 说明 |
|---|---|
| 段基址/界限寄存器 | 每个段都得有这俩寄存器，基址记段的起始地址，界限记段的大小，防止越界 |
| 段选择 | 靠虚拟地址（逻辑地址）的某些位，找到对应的段，相当于“选段钥匙” |
| 反向增长 | 栈是向下增长的，MMU得支持这种反向增长的段，不然栈就乱了 |
| 权限 | 给每个段标识读写、执行权限，比如代码段只能读和执行，不能写，不然容易被篡改 |
二、X86分段
说了这么多分段的基础，再说说X86架构里的分段，老一辈的程序员都知道，X86架构的历史包袱重得能压死人——这才是坑最多的地方，当年我啃这部分的时候，差点放弃内核开发。
为了兼容，X86硬生生在这套寻址体系里塞了三种地址。我就问你烦不烦？
第一种是逻辑地址（logical address），分段寻址的时候用的，由段（segment）和偏移量（offset）组成。偏移量就是这个地址相对于段起始位置的距离，很好理解吧？给你们看张图，看看逻辑地址的具体结构：
第二种是线性地址（linear address），逻辑地址经过分段映射后生成的，就是个32位的无符号整数，没啥花里胡哨的。
第三种是物理地址（physical address），线性地址再经过分页映射，最终得到的实际内存单元编号，数据就存在这个地址里。
这三种地址的转换，全靠MMU来完成，它们之间的转换路线图长这样：
再回头说逻辑地址，它的核心就是段选择符和偏移量。段选择符是用来定位段描述符（Segment Descriptor）的，而段描述符里，才真正存着段的属性信息。段选择符是16位的，里面有三个关键字段：
| 字段 | 说明 |
|---|---|
| index | 用来选择GDT或者LDT里的段描述符，相当于“描述符索引” |
| TI | 0选GDT（全局描述符表），1选LDT（局部描述符表），二选一 |
| RPL | 请求特权等级，决定了访问这个段需要的权限 |
GDT和LDT，说白了就是存段描述符的“表格”，GDT是全局的，整个系统就一个，起始地址和容量存在gdtr寄存器里；LDT是局部的，每个进程可能有一个，由ldtr寄存器记录。
X86架构的Linux里，常用的段描述符有三种：数据段描述符、代码段描述符、系统段描述符（比如任务状态段）。给你们看张图，看看这三种描述符的结构，虽然看着复杂，但核心字段就那几个：
这些描述符里的信息，其实和咱们之前说的MMU分段需求是对应的，我挑几个关键的说说：
BASE是段的起始地址，LIMIT是段的大小，DPL是描述符特权等级（和RPL对应），G位是粒度位——G=0的时候，按字节算大小；G=1的时候，按4K字节算，这个我当年搞错过一次，把G位设成1，结果段大小算错了，导致内存越界，查了半天才找到问题。
搞懂了段选择符和GDT/LDT，逻辑地址转线性地址的流程就很简单了，看下图：
第一步，看段选择符的TI位，决定用GDT还是LDT；第二步，用段选择符的Index，定位到GDT/LDT里的段描述符——因为每个段描述符占8字节，所以用GDT/LDT的起始地址，加上Index乘以8，就能找到目标描述符；第三步，把段描述符里的BASE和逻辑地址的偏移量加起来，得到的就是线性地址，是不是很简单？
三、内核分段
前面说了这么多X86的分段，你们肯定以为Linux内核里也用得风生水起吧？
错了！实际开发里，Linux内核早就弃用了硬件层面的传统分段机制，为啥呢？全是坑啊。
传统分段靠基址计算，麻烦得很。首先，进程切换的时候，得保存和还原所有段寄存器的内容，耗时又麻烦；其次，每个进程的地址空间划分不一样，长期运行下来，物理内存会出现很多碎片，浪费内存；最关键的是，现在很多处理器架构（比如RISC）根本不支持分段，为了跨平台兼容，Linux只能放弃传统分段，改用页表管理。
不过X86架构下，GDT还是得有，不然系统启动不了。Linux的GDT一共有32个条目，里面最关键的就是4个：内核代码段、内核数据段、用户态默认代码段、用户态默认数据段。
给你们看段源码，这是Linux里GDT的布局，我写了注释，尽量能让大家都能看懂：
/** Linux下每个CPU的GDT布局说明（注释是我加的，方便新手理解）* 0号条目：空描述符（必须有，占位用） <=== 第一个缓存行* 1-3号条目：保留，暂不用* 4-5号条目：未使用 <=== 第二个缓存行* ------- TLS段开始（线程局部存储，比如glibc、Wine会用到）：* 6号条目：TLS段1 [ glibc的TLS段 ]* 7号条目：TLS段2 [ Wine的%fs Win32段 ]* 8号条目：TLS段3 <=== 第三个缓存行* 9-11号条目：保留* ------- 内核段开始：* 12号条目：内核代码段<=== 第四个缓存行* 13号条目：内核数据段* 14号条目：默认用户态代码段* 15号条目：默认用户态数据段* 16号条目：TSS（任务状态段） <=== 第五个缓存行* 17号条目：LDT（局部描述符表）* 18-25号条目：PNPBIOS和APM BIOS相关支持（老硬件用，现在基本用不上）* 26号条目：ESPFIX small SS（栈相关，修复栈指针问题）* 27号条目：per-cpu [ 指向每个CPU的专属数据区 ]* 28号条目：stack_canary-20 [ 栈保护，防止栈溢出 ] <=== 第八个缓存行* 29-30号条目：未使用* 31号条目：双重故障处理程序的TSS（防止系统崩溃）*/
Linux内核启动的时候，会通过宏定义来构建GDT，下面这段代码就是构建GDT的核心，可以看看（不用死记，知道大概逻辑就行）：
// 定义GDT条目初始化宏，参数分别是：标志位、基址、界限#define GDT_ENTRY_INIT(flags, base, limit) \{ \.limit0 = (u16) (limit), // 界限的低16位.limit1 = ((limit) >> 16) & 0x0F, // 界限的高4位（和G位配合）.base0 = (u16) (base), // 基址的低16位.base1 = ((base) >> 16) & 0xFF, // 基址的中8位（16-23位）.base2 = ((base) >> 24) & 0xFF, // 基址的高8位（24-31位）.type = (flags & 0x0f), // 段类型（代码段/数据段等）.s = (flags >> 4) & 0x01, // 0表示系统段，1表示代码/数据段.dpl = (flags >> 5) & 0x03, // 描述符特权等级（0-3）.p = (flags >> 7) & 0x01, // 存在位（1表示段存在，0表示不存在）.avl = (flags >> 12) = (flags >> 13) & 0x01, .d = (flags >> 14) & 0x01, .g = (flags >> 15) & 0x01, }// 定义每个CPU的GDT页面（按页对齐），初始化GDT条目_PER_CPU_PAGE_ALIGNED(struct gdt_page, gdt_page) = { .gdt = {#ifdef CONFIG_X86_64/* 64位模式下，也需要有效的段* IRET指令会检查段类型（kkeil 2000/10/28注）* sysret指令要求特定的GDT布局位不一样，希望没人依赖固定位置（比如Wine？）[GDT_ENTRY_KERNEL32_CS] = GDT_ENTRY_INIT(0xc09b内核代码段[GDT_ENTRY_KERNEL_CS] = G 0, 0xfffff), // 64位内核代码段[GDT_ENTRY_KERNEL_DS]_ENTRY_INIT(0xc093, 0, 0xfffff), // 内核数据段[GDT_ENTRY_DEFAULT_CS] = GDT_ENTRY_INIT(0xc0fb, 0, 0xfffff), // 32位用户DT_ENTRY_DEFAULT_USER_DS] = GDT_ENTRY_INIT(0xc0f3, 0, 0xfffff), // [GDT_ENTRY_DEFAULT_USER_CS] = GDT_ENTRY_INIT(0xa0fb, 0, 0位用户代码段#else// 32位模式下的GDT条目[GDT_E] = GDT_ENTRY_INIT(0xc09a, 0, 0xfffff), _ENTRY_KERNEL_DS] = GDT_ENTRY_INIT(0xc092, 0, 0x数据段[GDT_ENTRY_DEFAULT_USER_CS] = GDT_ENTRY_IN0xfffff), // 用户代码段[GDT_ENTRY_DEFAULT_USER_DS] = G0xc0f2, 0, 0xfffff), // 用户数据段/* 用于调用PN段，字节粒度，代码/数据段固定64K界限* 传输设置*/[GDT_ENTRY_PNPBIOS_CS32] = GDT_ 0xffff), // 32位PNP BIOS代码段[GDT_ENTRY_PNPBIOS_CS16] _INIT(0x009a, 0, 0xffff), // 16位PNP BIOS代码段[GDT_NPBIOS_DS] = GDT_ENTRY_INIT(0x0092, 0, 0xffff), // 16[GDT_ENTRY_PNPBIOS_TS1] = GDT_ENTRY_INIT(0x0092, 0 16位PNP BIOS传输段1[GDT_ENTRY_PNPBIOS_TS2] 092, 0, 0), // 16位PNP BIOS传输段2/* APM ，字节粒度，基址运行时设置，界限64K*/_APMBIOS_BASE] = GDT_ENTRY_INIT(0x409a, 0, 0xffff), // BIOS代码段[GDT_ENTRY_APMBIOS_BASE+1] = GDT_ENa, 0, 0xffff), // 16位APM BIOS代码段[GDT_ENTRY_APMBIOS_B= GDT_ENTRY_INIT(0x4092, 0, 0xffff), // APM BIOS数据段[GD_ESPFIX_SS] = GDT_ENTRY_INIT(0xc092, 0, 0xfffff段[GDT_ENTRY_PERCPU] = GDT_ENTRY_INIT(0xc092, 0, 0xfGDT_STACK_CANARY_INIT // 栈保护初始化#endif}ffff), // per-cpu数据段), // ESPFIX栈T_ENTRYASE+2] TRY_INIT(0x009 32位APM [GDT_ENTRYBIOS相关段 = GDT_ENTRY_INIT(0x0, 0), //位PNP BIOS数据段ENTRY_P = GDT_ENTRYENTRY_INIT(0x409a, 0,段大小在运行时P BIOS的DT_ENTRY_INIT(IT(0xc0fa, 0, fffff), // 内核// 内核代码段[GDTNTRY_KERNEL_CSxfffff), // 64 用户数据段代码段[G_USER32 = GDTDT_ENTRY_INIT(0xa09b,, 0, 0xfffff), // 32位 */* TLS描述符的位置和32释，保留原注释内核代码/数据DEFINE // 粒度位（1表示4K，0表示字节）// 32位模式标志（1表示32位）// 64位模式标志（1表示64位）& 0x01, // 保留位，可自定义使用.l
从这段代码能看出来，GDT_ENTRY_INIT宏主要初始化了四个关键的段描述符：内核代码段（KERNEL_CS）、内核数据段（KERNEL_DS）、用户代码段（USER_CS）、用户数据段（USER_DS）。
它们的参数我整理成了一个表：
| 段 | BASE | Limit | G | S | DPL | P | Type |
|---|---|---|---|---|---|---|---|
| KERNEL_CS | 0 | 0XFFFF | 1 | 1 | 0 | 1 | 0xA |
| KERNEL_DS | 0 | 0XFFFF | 1 | 1 | 0 | 1 | 0x2 |
| USER_CS | 0 | 0XFFFF | 1 | 1 | 3 | 1 | 0xA |
| USER_DS | 0 | 0XFFFF | 1 | 1 | 3 | 1 | 0x2 |
这里有个关键点，你们发现没？
这四个段的BASE都是0！也就是说，逻辑地址的偏移量，和线性地址是一样的。DPL字段是权限等级，内核态是0，用户态是3，这样就能保证内核态的段，用户态程序没法随便访问。
所以啊，虽然X86架构支持分段，但Linux内核实际上没怎么用传统分段机制，主要还是靠页表管理内存。毕竟分段的坑太多，不如分页灵活、高效。
至于分页机制的具体实现，我昨天写过，感兴趣的可以看一看→深入浅出Linux内核（内存篇）：页表映射分页
随机文章
-
10个月宝宝每天需要喝多少奶粉？
- 豆豆的Python生活 16 万卷书库(一)初识数据库
- 韩师python复习题库
- 近年来最严重的Linux威胁出现,一个脚本即可获得root权限
- Python 异常处理:try-except 基础结构 + try-except-else-finally 完整精讲
- 39个实用Linux命令,运维必收藏!
- 9天玩转Python编程.大模型学习路线笔记
- Arch Linux 26.05 发布!
- 【科研必备】植被参数光学遥感反演方法(Python)及遥感与生态模型数据同化算法技术应用
- 远洋课堂—Python AI 大模型部署全攻略:本地运行 + API 服务 + Docker 封装
- 数百行 Python 变拖拽,AgentSwarms 让 AI 自己查图重跑