目录 1 概述 IA-32 体系结构内存地址映射 CPU 相关寄存器系统寄存器内存管理寄存器保护模式的内存管理位时页面机制地址映射逻辑地址到线性地址的映射...9

Size: px

Start display at page:

Download "目录 1 概述 IA-32 体系结构内存地址映射 CPU 相关寄存器系统寄存器内存管理寄存器保护模式的内存管理位时页面机制地址映射逻辑地址到线性地址的映射...9"

挥短赵
5 years ago
Views:

1 Linux 内存地址映射

2 目录 1 概述 IA-32 体系结构内存地址映射 CPU 相关寄存器系统寄存器内存管理寄存器保护模式的内存管理位时页面机制地址映射逻辑地址到线性地址的映射线性地址到物理地址的映射 PAE 页面机制地址映射过程 PDPTE 寄存器逻辑地址到线性地址的映射线性地址到物理地址的映射 Linux 内核的地址映射过程段式映射过程页式映射过程 Linux 地址映射实验 gdtr 和 cr3 寄存器值的获取读取物理内存上的数据地址映射过程实验段式映射过程页式映射过程 PAE 机制下地址映射过程实验段式映射过程页式映射过程常见问题及解答...28

3 1 概述结果 : 在分析 Linux 内存地址映射前, 先来看一段简单的 C 程序代码在 32 位和 64 位系统上运行 #include <stdio.h> int main() { unsigned long tmp; tmp = 0x ; printf("tmp variable address:0x%08lx\n", &tmp); } return 0; [root@rhel6 C]#./addr tmp variable address:0xbff42dec [root@rhel6 C]# [root@rhel6-x64-1 C]#./addr tmp variable address:0x7fff138e0888 上面的程序功能非常简单, 就是打印出临时变量 tmp 的地址程序运行后在 32 位系统中 tmp 地址为 0xBFF42DEC, 在 64 位系统中打印地址为 0x7FFF138E0888( 注意 : 每次运行的结果都可能不同 ) 那么这个地址对是逻辑地址, 还是线性地址? 物理地址? 临时变量 tmp 到底存放在物理内存的哪个位置上? 在 Intel 体系结构的 CPU 中, 现代操作系统如 Linux 都采用内存保护模式来管理内存我们看 Linux 内核中的内存管理相关内容时, 会遇到一个基本问题 : 普通用户程序中的地址是如何转换到内存上的物理地址的?IA-32 架构的 CPU 规定地址映射过程是逻辑地址线性地址物理地址 Linux 既然能在 Intel 架构的 CPU 上运行, 就要遵守这个规定, 那么 Linux 又是如何进行地址映射的? 本文以 RHEL5.8 i686 内核源码版本 ( 源码下载地址

4 ftp://ftp.redhat.com/pub/redhat/linux/enterprise/5server/en/os/srpms/), 在 IA-32 架构 CPU 为基础, 分析 CPU 架构下的地址映射过程及 Linux 内核中的实现, 并给出一些工具 ( 附源码 ) 来验证整个地址映射过程 ( 包括 PAE 机制下的映射 ), 方便我们更直观和深入理解 Linux 在 x86 CPU 地址映射对于 Linux 内核在 x64_64 CPU 中的地址映射过程, 会在另外一篇文章中单独介绍 2 IA-32 体系结构内存地址映射 2.1 CPU 相关寄存器 IA-32 架构中提供了 10 个 32 位和 6 个 16 位的寄存器这些寄存器分为三大类 : 通用寄存器控制寄存器段寄存器通用寄存器进而分为数据指针和索引寄存器通用寄存器包括 EAX EBX ECX EDX ESI EDI EBP ESP 数据寄存器有 EAX EBX ECX EDX, 索引寄存器是两个 :ESI(Source Index) EDI(Destination Index), 这两个寄存器都和字符串处理指令相关指针寄存器也有两个 : ESP(Stack Pointer) 和 EBP(Base Pointer), 这两个寄存器主要来维护栈我们知道程序运行和函数调用时, 都用到栈, 不同的程序以及程序中不同的函数, 都有各自的栈空间, 那么怎么来维护不同的栈? 寄存器 ESP 就是指向当前栈的栈顶, 而寄存器 EBP 指向当前栈的栈底注意程序运行及函数调用时, 不同的栈,EBP 和 ESP 的值都不同

图 1 通用寄存器段寄存器和控制寄存器控制寄存器有 2 个 :EIP 和 EFLAGS 处理器使用 EIP 来跟踪下一条要执行的指令, 也称为程序计数寄存器段寄存器有 6 个 :CS ES DS FS GS SS 2.1.1 系统寄存器为了初始化 CPU

包含用来控制系统级别操作的数据和信息 ; 其他一些标志来只是 CPU 的特殊功能 ;CR3 寄存器, 对本文很重要, 后面会详细介绍它的功能以及如何获取 CR3 积存器的值 (3) 调试寄存器允许设置程序的断点, 以调试程序和系统软件 ; (4)GDTR LDTR 和 IDTR

5 图 1 通用寄存器段寄存器和控制寄存器控制寄存器有 2 个 :EIP 和 EFLAGS 处理器使用 EIP 来跟踪下一条要执行的指令, 也称为程序计数寄存器段寄存器有 6 个 :CS ES DS FS GS SS 系统寄存器为了初始化 CPU 和控制系统操作,IA-32 提供了 EFLAGS 寄存器和几个系统寄存器 EFLAGS 寄存器用来保存系统的一些状态标志 (1)EFLAGS 寄存器中的 IOPL 域, 控制任务和模式的切换中断处理指令跟踪和访问权限 ; (2) 控制寄存器 (CR0 CR2 CR3 和 CR4) 包含用来控制系统级别操作的数据和信息 ; 其他一些标志来只是 CPU 的特殊功能 ;CR3 寄存器, 对本文很重要, 后面会详细介绍它的功能以及如何获取 CR3 积存器的值 (3) 调试寄存器允许设置程序的断点, 以调试程序和系统软件 ; (4)GDTR LDTR 和 IDTR 寄存器 (5) 任务寄存器 (6) 型号相关的寄存器图 2 系统寄存器内存管理寄存器处理器提供了 4 个内存管理寄存器 :GDTR LDTR IDTR 和 TR 这 4 个寄存器在前面一小节 ( 系统寄存器 ) 中提到, 我们关心地址映射 ( 内存管理 ) 相关的寄存器, 故这里详细介绍一下

6 图 3 内存管理寄存器 1. Global Descriptor Table Register(GDTR) GDTR 寄存器保存 GDT 的基址和表限 (table limit) 基址是 GDT 的第一个字节的地址, 表限 (table limit) 给出表的大小指令 LGDT 和 SGDT 是分别用来设置和保存 GDTR 寄存器的值上电或重启处理器后, 基址默认的值为 0, 表限 (table limit) 的值为 0FFFFH 在保护模式运行前, 作为处理器初始化的一部分, 必须在 GDTR 寄存器中设置新的基址在后面的 Linux 地址映射过程中, 会用到 GDTR 寄存器在此顺便介绍一下汇编指令 SGDT, 即获取 GDTR 寄存器的值 SGDT 指令的操作如下 : Operation IF instruction is IDTR THEN IF OperandSize 16 THEN DEST[0:15] IDTR(Limit); DEST[16:39] IDTR(Base); (* 24 bits of base address loaded; *) DEST[40:47] 0; ELSE (* 32-bit Operand Size *) FI; DEST[0:15] IDTR(Limit); DEST[16:47] IDTR(Base); (* full 32-bit base address loaded *) ELSE (* instruction is SGDT *) IF OperandSize 16 THEN DEST[0:15] GDTR(Limit); DEST[16:39] GDTR(Base); (* 24 bits of base address loaded; *) DEST[40:47] 0; ELSE (* 32-bit Operand Size *) FI; FI; DEST[0:15] GDTR(Limit); DEST[16:47] GDTR(Base); (* full 32-bit base address loaded *)

7 2. Local Descriptor Table Register(LDTR) LDTR 寄存器的值包括 :16 位的段选择码基址段限 (segment limit) 和 LDT 描述符属性基址是 LDT 段的起始地址, 段限是段的大小指令 LLDT 和 SLDT 是分别用来设置和保存 LDTR 寄存器的值 3. Interrupt Descriptor Table Register(IDTR) IDTR 寄存器的内容是 :IDT 的基址和大小指令 LIDT 和 SIDT 是分别用来设置和保存 IDTR 寄存器的值 4. Task Register(TR) TR 寄存器的内容包括 :16 位的段选择码基址段限 (segment limit) 和描述符的属性由于 Linux 中没有使用 TR 寄存器, 这里不作详细介绍介绍这些 CPU 寄存器时, 很多人一脸茫然这 4 个内存管理寄存器的用途是什么? 何时会用到? 这里只是简单介绍, 随着地址映射过程的逐步分析, 再回过头来看这部分内容, 就会很容易明白其用途和何时用 2.2 保护模式的内存管理在 IA-32 架构中, 内存管理分为两块 : 分段和分页分段机制是将代码数据和栈分开, 这样处理器上运行多个程序, 不会相互影响分页是操作系统可以实现按需分页和虚拟内存功能分页也可以用来隔离多个任务当运行在保护模式时, 分段的基址是必须使用的, 不能关闭分段功能 ; 然而分页是可选的在 Linux 系统中, 实际上是没有真正使用 IA-32 的分段机制, 仅使用分页机制在分析地址映射过程之前, 先描述几个概念 : 逻辑地址 (Logical Addres) 线性地址 (Linear Address) 和物理地址 (Physical Address) 逻辑地址是在机器语言指令中, 来说明操作数和指令的地址 ; 每个逻辑地址包括两部分 : 段

8 (Segment) 和偏移量 (Offset) 线性地址也通常成为虚拟地址, 在 32 位系统中, 它是 32 位的无符号整型, 最大可以达到 4G 物理地址就是真正物理内存上的地址图 5 是 IA-32 中的段页式模型图 4 地址映射过程图 5 IA-32 中的分段和分页从图 5 可以看出, 地址映射过程是逻辑地址线性地址物理地址也就是要经过两个映射过程 : 第一步是段式映射, 第二步是页式映射当一条访问内存指令发出一个内存地址时 ( 大家思考一下, 此时 CPU 发出的地址类型是逻辑地址? 还是线性地址? 还是物理地址?)CPU 就按照段式映射和页式映射两个步骤来计算出实际上应该放在数据总线的地址, 大家也许会感到访问内存, 计算地址时这么麻烦! 在本文最后会给出工具和源码来查看

9 和验证整个地址映射过程, 大家有一个更为直观的认识位时页面机制地址映射逻辑地址到线性地址的映射前面一节介绍了 IA-32 内存管理模型, 及段式映射过程页式映射过程, 但只是一些概要性的介绍现在我们看一下更为详细的过程图 6 逻辑地址到线性地址映射过程从逻辑地址到线性地址的映射过程如下 : (1) 根据指令的性质来确定应该使用哪一个段寄存器, 例如转移指令中的地址在代码段, 而取数据指令中的地址在数据段 ; (2) 根据段存器的内容, 找到相应的地址段描述结构, 段描述结构都放在一个表中 (GDT 或 LDT TR IDT), 而表的起始地址保存在 GDTR LDTR IDTR TR 寄存器中这就是 4 个内存管理寄存器 GDTR LDTR IDTR 和 TR 的用途 ; (3) 从地址段描述结构中找到基地址 ; (4) 将指令发出的地址作为位移, 与段描述结构中规定的段长度相比, 看看是否越界 ; (5) 根据指令的性质和段描述符中的访问权限来确定是否越权 ; (6) 将指令中发出的地址作为位移, 与基地址相加而得出线性地址从逻辑地址到线性地址映射过程, 有几个细节地方需要关注两个问题 : a) 逻辑地址就是 CPU 指令发出的地址, 那么段选择码 (Segment Selector) 的值在哪里? b) 知道段选择码后, 需要从描述符表 (Descriptor Table) 中找到相应的表项, 那怎

10 么知道描述符表在内存中哪个位置? 第一个问题的答案是段选择码在段寄存器中 ( 回忆一下 IA-32 中的 6 个段寄存器 ), 如 CS DS 等第二个问题的答案是描述符表的基址在内存管理寄存器中 (GDTR LDTR IDTR TR) 当然每个地址只会对应一个段寄存器和内存管理寄存器知道了从哪里取段选择码 (Segment Selector), 也知道了从内存的哪个位置取段描述符, 那么段选择码和段描述符的内容是怎样的? 图 7 段选择码图 8 段描述符图 7 和图 8 分别是段选择码和段描述符的结构段寄存器的高 13 位 ( 低 3 位另作他用 ) 用作访问段描述表中具体描述结构的下标 (index) GDTR 或 LDTR 中的段描述表指针和段寄存器中给出的下标结合在一起, 才决定了具体的段描述表项在内中的什么地方从图 8 的段描述符结构中, 我们注意段基址 (Base Address 15:00 Base 23:16 Base 31:24) 和段限 (Segment Limit 15:00)

11 图 9 全局和局部描述符表线性地址到物理地址的映射上面是将逻辑地址映射为线性地址的过程, 此时还要将线性地址转换为物理地址, 才是真正要访问的内存地址从线性地址到物理地址的映射过程为 : (1) 从 CR3 寄存器中获取页面目录 (Page Directory) 的基地址 ; (2) 以线性地址的 dir 位段为下标, 在目录中取得相应页面表 (Page Table) 的基地址 ; (3) 以线性地址中的 page 位段为下标, 在所得到的页面表中获得相应的页面描述项 ; (4) 将页面描述项中给出的页面基地址与线性地址中的 offset 位段相加得到物理地址图 10 线性地址到物理地址的映射过程

图 11 32bit 页面机制时 CR3 寄存器和页面项对上面的步骤做一下补充说明 CR3 寄存器的值从哪里来的? 每个进程都会有自己的地址空间, 页面目录也在内存不同的位置上, 这样不同进程就有不同的 CR3 寄存器的值 CR3 寄存器的值一般都保存在进程控制块中, 如 linux 中的 task_struct 数据结构中 2.

12 图 11 32bit 页面机制时 CR3 寄存器和页面项对上面的步骤做一下补充说明 CR3 寄存器的值从哪里来的? 每个进程都会有自己的地址空间, 页面目录也在内存不同的位置上, 这样不同进程就有不同的 CR3 寄存器的值 CR3 寄存器的值一般都保存在进程控制块中, 如 linux 中的 task_struct 数据结构中 2.4 PAE 页面机制地址映射过程 PAE(Physical Address Extension) 是 IA-32 架构中物理地址扩展机制在正常情况下,32 位系统只能使用 4G 物理内存, 但使能 PAE 机制后使地址总线达到 36 根, 最大可以访问 64G 物理内存必须设置 CR0 寄存器的第 31bit 为 0(CR0.PG=1), 打开页式映射机制 ; 设置 CR4 寄存器第 5bit 为 1(CR4.PAE=1) 和 IA32_EFER..LMW=0, 使能 PAE 机制当逻辑处理器使用 PAE 页面机制时, 会将 32 位线性地址转换为 52 位物理地址 ( Intel 64 and IA-32 Architectures Software Developer's Manual Volume 3A System Programming Guide, Part 1 May 2012 章节 4.4 PAE Paging) PDPTE 寄存器当使用 PAE 机制时,CR3 寄存器的值是指向 32 字节对齐页面目录指针表 (Page Directory Pointer Table) 表 1 PAE 机制下 CR3 寄存器的使用页面目录指针表中共有 4 个 64bit 项, 称为 PDPTEs 每个 PDPTE 控制 1G 线性地址空间的访问对应 PDPTE, 逻辑处理器维护 4 个架构无关的内部 PDPTE 寄存器, 分别为 PDPTE0 PDPTE1 PDPTE2 PDPTE3

13 表 2 PAE 机制下 PDPTE 格式逻辑地址到线性地址的映射 PAE 机制仅与页面映射有关, 因此逻辑地址到线性地址映射过程一样详细步骤请参考前面非 PAE 机制下映射过程线性地址到物理地址的映射 PAE 机制可以映射 4K 页面或者 2MB 页面, 在此我们仅考虑 4K 页面的映射过程, 如下图所示图 12 PAE 机制下线性地址到物理地址的映射过程从线性地址到物理地址的映射过程为 : (1)PDPTE 值的来源线性地址的 30~31bit 用来选择 PDPTE 寄存器, 即 PDPTEi,i 的值就是 31:30 的值因为线性

14 地址的 31:30 两个 bit 用来选择 PDPTE 寄存器, 因此只能控制访问 1GB 的线性地址空间当 PDPTEi 寄存器的 P 标志位 (bit 0) 值为 0 时,CPU 就忽略 63:1, 表示该寄存器控制的 1GB 线性地址空间没有对应的映射 ( 即这段线性地址还没有分配相应的物理内存 ), 当访问这段线性地址时, 就会产生页面错误异常 (2) 页面目录表项当 PDPTEi 寄存器的 P 标志位为 1 时, 页面目录表 (Page Directory Table) 的地址在 PDPTEi 寄存器的 51:12( 相当于非 PAE 机制下 CR3 寄存器的值 ) 页面目录表由 512 个 64bit 页面目录项 (Page Directory Entry) 组成具体目录项 (PDE) 物理地址计算方法 : Bits 51:12 来自 PDPTEi ( 页面目录表的地址 ) Bits 11:3 是线性地址的 bit29:21 ( 页面目录表内偏移 ) Bits 2:0 为 0 (3) 页面表项 PDE( 页面目录项 ) 的 51:12 是页面表的起始物理地址具体的页面表 (PTE) 物理地址计算方法 : Bits 51:12 来自 PDE( 页面表的起始地址 ) Bits 11:3 是线性地址的 bit20:12 ( 页面表内偏移 ) Bits 2:0 为 0 (4) 最终物理地址的计算方法 Bits 51:12 来自 PTE( 页面的起始地址 ) Bits 11:0 是线性地址的 bit20:12 ( 页面内偏移 ) 图 13 PAE 页面机制时 CR3 寄存器和页面项

15 3 Linux 内核的地址映射过程 Linux 内核要在 IA-32 架构上运行, 就要进行前面介绍的地址映射过程很多人看地址映射内容, 感觉是云里雾里, 本身内容也比较抽象现在开始结合 Linux 内核中的源码来分析我们写的普通应用程序的地址映射过程在概述中, 我们给出了一个小程序, 程序运行后打印临时变量 tmp 的地址为 0xBFF42DEC 也许大家会有个疑问, 这个地址到底是逻辑地址? 线性地址? 物理地址? 事实上, 打印的结果只是逻辑地址, 而不是真正的物理地址既然打印的结果 0xBFF42DEC 是逻辑地址, 那么我们就可以以此作为开始, 来逐步解析整个地址映射过程 3.1 段式映射过程段式映射过程实际上就是从逻辑地址到线性地址的映射过程临时变量 tmp 的逻辑地址为 0xBFF42DEC, 那么在段式映射过程中 ( 见图 6), 它就是偏移量 (offset) 现在已经知道了偏移量, 但还不知道段选择码临时变量 tmp 存放在栈中,IA-32 提供了 SS(Stack Segment) 寄存器, 那就从 SS 寄存器中读取段选择码内核在建立一个进程时都要将其段寄存器设置好, 有关代码在 include/asm/processor.h ( 注意 : 内核源码版本为 el5) 00531: 00532: #define start_thread(regs, new_eip, new_esp) do { \ 00533: asm ("movl %0,%%fs ; movl %0,%%gs": :"r" (0)); \ 00534: set_fs(user_ds); \ 00535: regs- >xds = USER_DS; \ 00536: regs- >xes = USER_DS; \ 00537: regs- >xss = USER_DS; \ 00538: regs- >xcs = USER_CS; \ 00539: regs- >eip = new_eip; \ 00540: regs- >esp = new_esp; \ 00541: preempt_disable(); \ 00542: load_user_cs_desc(smp_processor_id(), current- >mm); \ 00543: preempt_enable(); \ 00544: } while (0) IA-32 中有 6 个段寄存器 Linux 内核建立一个进程时把 DS ES SS 寄存器的值都设为 USER_DS,CS 寄存器的值设为 USER_CS, 而另外两个段寄存器 FS 和 GS 都设为 0 这样 Linux 中事实上只有只使用了两个段 : 代码段 (CS) 和数据段 (DS) 而且每个进程

16 的 6 个段寄存器值都相同, 只有 EIP 和 ESP 值不同虽然 Linux 中进程只分两个段 ( 代码段和数据段 ), 但 IA-32 的处理器并不知道操作系统把程序分为多少个段接着前面临时变量 tmp 的逻辑地址转换到线性地址过程, 偏移量已经知道为 0xBFF42DEC, 因为 tmp 在栈中, 那么就要从 SS 寄存器中读取段选择码而 SS 寄存器的值为 USER_DS, 其值定义在文件件 include/asm/segment.h 中 00053: 00054: #define GDT_ENTRY_DEFAULT_USER_CS : #define USER_CS (GDT_ENTRY_DEFAULT_USER_CS * 8 + 3) 00056: 00057: #define GDT_ENTRY_DEFAULT_USER_DS : #define USER_DS (GDT_ENTRY_DEFAULT_USER_DS * 8 + 3) USER_CS(14*8 +3 = 115) 的值展开二进制的结果为 : USER_DS(15*8 + 3 =123) 的值展开二进制的结果为 : 高 13 位为 index, 而第三个 bit 都为 0, 表示仅使用 GDT(Global Descriptor Table), 而没有使用 LDT(Local Descriptor Table) 事实上,Linux 确实没有使用 LDT LDT 只是在 VM86 模式中运行 wine 以及其他在 Linux 上模拟运行 Windows 软件或 DOS 软件的程序中才使用现在确定了偏移量 (offset) 和段选择码中的 index, 也确定了是从 GDT 表中, 以 15(index) 为下标, 找到相应的段描述符 (segment descriptor), 从段描述符中找到段的基址是多少, 段限又是多少? GDT 表在内存中的位置, 是由 GDTR 寄存器保存的 IDT 表中的值是在操作系统启动时设置好的, 在本文最后的实验内容中再给出如何读 GDTR 的值及段描述符事实上, 全局描述表中的表项值在文件 arch/i386/kernel/head.s 中, 先将该文件中的一段代码截取出来 00486: /* 00487: * The Global Descriptor Table contains 28 quadwords, per-cpu : */ 00489:.align L1_CACHE_BYTES 00490: ENTRY(cpu_gdt_table) 00491:.quad 0x /* NULL descriptor */ 00492:.quad 0x /* 0x0b reserved */ 00493:.quad 0x /* 0x13 reserved */ 00494:.quad 0x /* 0x1b reserved */ 00495:.quad 0x /* 0x20 unused */ 00496:.quad 0x /* 0x28 unused */

17 00497:.quad 0x /* 0x33 TLS entry 1 */ 00498:.quad 0x /* 0x3b TLS entry 2 */ 00499:.quad 0x /* 0x43 TLS entry 3 */ 00500:.quad 0x /* 0x4b reserved */ 00501:.quad 0x /* 0x53 reserved */ 00502:.quad 0x /* 0x5b reserved */ 00503: 00504:.quad 0x00cf9a000000ffff /* 0x60 kernel 4GB code at 0x */ 00505:.quad 0x00cf ffff /* 0x68 kernel 4GB data at 0x */ 00506:.quad 0x00cffa000000ffff /* 0x73 user 4GB code at 0x */ 00507:.quad 0x00cff ffff /* 0x7b user 4GB data at 0x */ 00508: 00509:.quad 0x /* 0x80 TSS descriptor */ 00510:.quad 0x /* 0x88 LDT descriptor */ 00511: 因为我们得到的 index 为 15( 二进制为 1111), 那么就对应下面一项.quad 0x00cff ffff /* 0x7b user 4GB data at 0x */ 我们再来对照图 7 来确定段的基址和段限 (segment limit) 0~15,48~51bits 为 Segment Limit 而段的基址是 16~31,32~39,56~63bits 组成所以段限的值为 0xfffff, 而段的基址值为 0(16~31,32~39,56~63bits 全为 0) 而 G 为都是 1, 段长为 4KB, 而上限为 0xfffff, 这样数据段就是从 0 地址开始的整个 4G 虚存空间, 逻辑地址到线性地址的映射保持不变 ( 因为段的基址为 0) 事实上, 代码段也是如此, 大家有兴趣可以自行分析一下我们终于完成了逻辑地址到线性地址映射的过程, 段式映射结束后, 发现逻辑地址和虚拟地址是一样的, 没有变化临时变量 tmp 的逻辑地址为 0xBFF42DEC, 段式映射后的线性地址也为 0xBFF42DEC 3.2 页式映射过程页式映射过程就是将线性地址映射到物理地址的过程临时变量 tmp 的逻辑地址为 0xBFF42DEC, 段式映射后的线性地址也 0xBFF42DEC, 现在将线性地址 0xBFF42DEC 映射到真正的物理地址, 就是放在地址总线上的地址

18 为了使 Linux 能在 32 位和 64 位 CPU 上运行, 就要采用统一的页面地址模型从内核开始, 页面地址模型采用了 4 级页面, 如图 14 所示图 14 Linux 页式地址模型在第二部分内容中, 我们描述了 IA-32 的页式映射过程完成线性地址到物理地址的映射过程, 有一个寄存器很重要, 就是 CR3 寄存器知道 CR3 寄存器的值, 我们就知道该进程的页面目录在内存中的位置, 根据 dir 位段, 找到相应的页面表, 再根据 Table 位段, 就可以找到 tmp 所在页面的起始地址 CR3 寄存器的值是从哪里设置的? 内核在创建进程时, 会分配页面目录, 页面目录的地址就保存在 task_struct 结构中,task_struct 结构中有个 mm_struct 结构类型的指针 mm, mm_struct 结构中有个字段 pgd( 见下面代码 429 行 ) 就是用来保存该进程的 CR3 寄存器的值下面一段代码来自 kernel/fork.c, 创建进程时, 需要分配一个页面目录 00427: static inline int mm_alloc_pgd(struct mm_struct * mm) 00428: { 00429: mm- >pgd = pgd_alloc(mm); 00430: if (unlikely(! mm- >pgd)) 00431: return - ENOMEM; 00432: return 0; 00433: } 下面一段代码是切换进程时, 地址空间的切换过程注意 41 行就是加载即将运行进程

19 的页面目录地址到 CR3 寄存器中下面一段代码摘自 include\asm\mmu_context.h 00025: static inline void switch_mm(struct mm_struct *prev, 00026: struct mm_struct *next, 00027: struct task_struct *tsk) 00028: { 00029: int cpu = smp_processor_id(); 00030: 00031: if (likely(prev!= next)) { 00032: /* stop flush ipis for the previous mm */ 00033: cpu_clear(cpu, prev- >cpu_vm_mask); 00034: #ifdef CONFIG_SMP 00035: per_cpu(cpu_tlbstate, cpu).state = TLBSTATE_OK; 00036: per_cpu(cpu_tlbstate, cpu).active_mm = next; 00037: #endif 00038: cpu_set(cpu, next- >cpu_vm_mask); 00039: 00040: /* Re-load page tables */ 00041: load_cr3(next- >pgd); 00042: 00043: /* 00044: * load the LDT, if the LDT is different: 00045: */ 00046: if (unlikely(prev- >context.ldt! = next- >context.ldt)) 00047: load_ldt_nolock(&next- >context, cpu); 00048: } 00049: #ifdef CONFIG_SMP 00050: else { 00051: per_cpu(cpu_tlbstate, cpu).state = TLBSTATE_OK; 00052: BUG_ON(per_cpu(cpu_tlbstate, cpu).active_mm! = next); 00053: 00054: if (! cpu_test_and_set(cpu, next- >cpu_vm_mask)) { 00055: /* We were in lazy tlb mode and leave_mm disabled 00056: * tlb flush IPI delivery. We must reload %cr : */ 00058: load_cr3(next- >pgd); 00059: load_ldt_nolock(&next- >context, cpu); 00060: } 00061: } 00062: #endif 00063: }? end switch_mm? 后面我们会在实验中实际观察和验证地址映射过程 4 Linux 地址映射实验理论和架构的介绍是枯燥的, 现在我们可以做一些实验, 以更直观验证地址映射过程要想验证一下这个过程, 需要首先解决两个问题 :

20 (1) 需要知道 GDTR 和 CR3 寄存器的值 ; 验证 x86 段式映射时, 需要知道 Global Descriptor Table 的地址而该表的地址保存在 GDTR 寄存器中页式映射时, 需要知道页面目录表和 PDPTE 的物理地址, 这两个地址与控制寄存器 CR3 密切相关 (2) 要能查看所有物理内存的内容验证地址映射, 必然涉及到物理内存那么我们要解决如何访问指定物理地址存储的数据问题这两点普通用户程序肯定是没法做到的, 就需要内核编程, 然后结合用户编程这里说明一下, 以下编程环境和实验都在操作系统为 32 位 RHEL5.8, 内核版本为 el5 和 el5PAE 在使用以下代码前, 请确认环境,64 位系统中和其他内核版本 ( 如系列 ) 会有所差别 4.1 gdtr 和 cr3 寄存器值的获取在用户空间的程序中, 是无法直接获取 gdtr 和 cr3 寄存器的值, 因为访问这两个寄存器的值需要特权指令不过我们可以绕道达到获取这两个寄存器的值, 就是在 /proc 文件系统下创建一个文件, 通过该文件来获取用户程序的 cr3 寄存器和 gdtr 寄存器的值这需要内核编程读取 cr3 寄存器的值, 可以借助内核 asm/system.h 中提供的 API 来实现 gdtr 寄存器的值, 可以通过 sgdt 指令来读取示例代码如下 : struct gdtr_struct{ short limit; unsigned long address attribute ((packed)); }; static unsigned int cr0,cr3,cr4; static struct gdtr_struct gdtr; cr0 = read_cr0();

cr3 = read_cr3(); cr4 = read_cr4(); asm(" sgdt gdtr"); 代码编译后, 就可以通过命令 insmod 加载模块可以通过 /proc 文件系统来查看我们感兴趣的寄存器值, 那么在用户程序中就可以方便的获取当前进程的相关寄存器的值了, 读 /proc/sys_reg 文件即可 4.

21 cr3 = read_cr3(); cr4 = read_cr4(); asm(" sgdt gdtr"); 代码编译后, 就可以通过命令 insmod 加载模块可以通过 /proc 文件系统来查看我们感兴趣的寄存器值, 那么在用户程序中就可以方便的获取当前进程的相关寄存器的值了, 读 /proc/sys_reg 文件即可 4.2 读取物理内存上的数据前面一节可以获取到 gdtr 和 cr3 两个寄存器的值, 但页面目录页面表都保存在物理内存中有些数据在内核空间中, 如 GDT; 但有些在用户空间中, 如 PGD 和 PTE 用户空间是不能访问所有内存空间的, 但内核进程可以访问所有的物理内存显然, 我们仍可以通过内核编程和用户编程相结合查看所有的内存数据 Linux 用户程序如何访问物理内存, 详细内容看参考物理内存访问模块编译并加载到内核后, 在通过命令 mknod 在 /dev 目录下建议一个设备文件 #mknod /dev/phy_mem c 85 0 用户程序访问设备 phy_mem, 就可以访问内存上所有数据了这和用户程序获得一些寄存器值的方式一样 4.3 地址映射过程实验为了方便验证地址映射, 我们编写一个简单的应用程序该程序始终不退出 ( 因为一旦退出, 所对应的物理内存就会变化 ), 且可以读取自身进程的 CR3 GDTR 寄存器的值, 代码如下 : #define REGISTERINFO "/proc/sys_reg" #define BUFSIZE 4096

22 static char buf[bufsize]; static unsigned long addr; #define FILE_TO_BUF(filename, fd) do{ \ static int local_n; \ if (fd == - 1 && (fd = open(filename, O_RDONLY)) == - 1) { \ fprintf(stderr, "Open /proc/register file failed! \n"); \ fflush(null); \ _exit(102); \ } \ lseek(fd, 0L, SEEK_SET); \ if ((local_n = read(fd, buf, sizeof buf - 1)) < 0) { \ perror(filename); \ fflush(null); \ _exit(103); \ } \ buf [local_n] = 0; \ }while(0) int main() { unsigned long tmp; tmp = 0x ; static int cr_fd = - 1; asm("movl %ebp, %ebx\n movl %ebx, addr"); printf("\n%%ebp:0x%08lx\n", addr); printf("tmp address:0x%08lx\n", &tmp); FILE_TO_BUF(REGISTERINFO, cr_fd); printf("%s", buf ); } while(1); return 0; 将上面源码编译并执行执行步骤 : (1) 加载 dram.ko 驱动 ;( 以访问所有物理内存 ) (2) 加载 sys_reg.ko 驱动 ;( 读取系统寄存器 ) (3) 运行./mem_map 程序 (4) 使用 fileview 查看物理内存内容

我们得到 gdtr 寄存器的值中地址是 0xC2011000, 至于 gdtr 寄存器的数据格式, 请参照第二部分内容 gdtr 寄存器给出的值, 仍是线性地址其物理地址是 0x C2011000 - PAGE_OFFSET, 而 - PAGE_OFFSET 的值是 0xC0000000, 所以 GDT(Global Descriptor Table) 所在内存的物理地址是 0x2011000

23 我们得到 gdtr 寄存器的值中地址是 0xC , 至于 gdtr 寄存器的数据格式, 请参照第二部分内容 gdtr 寄存器给出的值, 仍是线性地址其物理地址是 0x C PAGE_OFFSET, 而 - PAGE_OFFSET 的值是 0xC , 所以 GDT(Global Descriptor Table) 所在内存的物理地址是 0x 段式映射过程临时变量 tmp 的地址为 0xBFD8E9A0, 这是个逻辑地址, 要将映射为物理地址, 首先是段式映射 gdtr 寄存器的值已经知道为 0x , 通过 fileview 程序查看该地址处的内容大家看到 GDT 中 index 为 15 的值确实为.quad 0x00cff ffff /* 0x7b user 4GB data at 0x */ 对照段式映射过程, 段式映射的结果是逻辑地址和线性地址是一样的, 即线性地址也是 0xBFD8E9A0

4.3.2 页式映射过程程序给出临时变量 tmp 的地址是 0xBFD8E9A0, 将其以二进制表示为 ( 高 10bit 中间 10bit 最后 12bit) 1011111111 0110001110 100110100000 也就是 dir( 高 10 位 ) 为 0x2ff, 由于每个数据项为 4 字节, 而 cr3 寄存器的值为 0x35B0F000, 所以该页面表的起始地址 ( 即

24 4.3.2 页式映射过程程序给出临时变量 tmp 的地址是 0xBFD8E9A0, 将其以二进制表示为 ( 高 10bit 中间 10bit 最后 12bit) 也就是 dir( 高 10 位 ) 为 0x2ff, 由于每个数据项为 4 字节, 而 cr3 寄存器的值为 0x35B0F000, 所以该页面表的起始地址 ( 即 Page Directory Entry) 为 0x35B0F000+0x2FF*4= 0x35B0FBFC 我们来看物理地址 0x35B0FBFC 地址中的内容得到的数据内容为 0x68F64067, 由于页面目录中的每一项都指向一个页面表, 页面表的起始地址肯定是页面大小的整数倍, 所以页面目录中每个数据项的低 12 位可作它用见图 15 所以指向的页面表起始地址为 0x68F P P P PAGE-TABLE BASE ADDRESS AVAIL G 0 A C W U W P S D T LEGEND P = Present (1=yes, 0=no) W = Writable (1 = yes, 0 = no) U = User (1 = yes, 0 = no) A = Accessed (1 = yes, 0 = no) G = Global (1 = yes, 0 = no) PS = Page-Size (0=4KB, 1 = 4MB) PWT = Page Write-Through (1=yes, 0 = no) PCD = Page Cache-Disable (1 = yes, 0 = no) 图 15 页面目录数据项格式内存 0x68F64000 处的是页面表的起始地址, 页面表内的偏移为 b, 即 0x18E, 所以临时变量 tmp 所在的页面起始地址保存在 0x68F x18E*4= 0x68F64638 处, 我们来看看物理地址 0x68F64638 处内存的数据, 该处的数据就是 tmp 变量所在的物理页面起始地址

我们可以看到 0x68F64638 处内存的数据为 0x699D7067 图 16 是页面表项数据格式, 低 12bit 是一些属性因此 tmp 变量所在的物理页面起始地址为 0x699D7000 31 12 11 10 9 8 7 6 5 4 3 2 1 0 P P PAGE-FRAME BASE ADDRESS AVAIL G 0 D A C W U W P D T LEGEND P =

25 我们可以看到 0x68F64638 处内存的数据为 0x699D7067 图 16 是页面表项数据格式, 低 12bit 是一些属性因此 tmp 变量所在的物理页面起始地址为 0x699D P P PAGE-FRAME BASE ADDRESS AVAIL G 0 D A C W U W P D T LEGEND P = Present (1=yes, 0=no) W = Writable (1 = yes, 0 = no) U = User (1 = yes, 0 = no) A = Accessed (1 = yes, 0 = no) D = Dirty (1 = yes, 0 = no) G = Global (1 = yes, 0 = no) PWT = Page Write-Through (1=yes, 0 = no) PCD = Page Cache-Disable (1 = yes, 0 = no) 图 16 页面表数据项格式 tmp 变量所在页面偏移量为 b, 即 0x9A0 因此 tmp 变量所对应的物理地址为 :0x699D x9A0 = 0x699D79A0 我们来看一下物理地址 0x699D79A0 存储的数据是什么通过我们的查看物理内存程序, 看到物理地址 0x699D79A0 存储的数据确实为 0x 终于找到程序中临时变量 tmp 在物理内存上的位置了, 即 tmp address:0xbfd8e9a0 对应的物理地址为 0x699D79A0 为此我们完整地验证了非 PAE 机制下地址映射的全过程

4.4 PAE 机制下地址映射过程实验在前面一节, 我们的实验是验证最简单地址映射过程但没有打开 PAE 时,32 位 Linux 内核只能使用 4G 物理内存打开 PAE 机制后, 最大可以使用 64G 物理内存,PAE 机制下的地址映射稍有不同本小节我们来验证 PAE 机制下地址映射过程下图是在 PAE 机制下, 运行结果 4.4.1 段式映射过程临时变量 tmp 的地址为 0xBF820B90, 这是个逻辑地址, 要将映射为物理地址, 首先是段式映射 gdtr 寄存器的值已经知道为 0x2011000, 通过 fileview 程序查看该地址处的内容大家看到 GDT 中 index 为 15 的值确实为.

26 4.4 PAE 机制下地址映射过程实验在前面一节, 我们的实验是验证最简单地址映射过程但没有打开 PAE 时,32 位 Linux 内核只能使用 4G 物理内存打开 PAE 机制后, 最大可以使用 64G 物理内存,PAE 机制下的地址映射稍有不同本小节我们来验证 PAE 机制下地址映射过程下图是在 PAE 机制下, 运行结果段式映射过程临时变量 tmp 的地址为 0xBF820B90, 这是个逻辑地址, 要将映射为物理地址, 首先是段式映射 gdtr 寄存器的值已经知道为 0x , 通过 fileview 程序查看该地址处的内容大家看到 GDT 中 index 为 15 的值确实为.quad 0x00cff ffff /* 0x7b user 4GB data at 0x */ 对照段式映射过程, 段式映射的结果是逻辑地址和线性地址是一样的, 即线性地址也是 0xBF820B90

4.4.2 页式映射过程程序给出临时变量 tmp 的地址是 0xBF820B90, 将其以二进制表示为 ( 高 2bit 中间 9bit 中间 9bit 最后 12bit) 10 111111100 000100000

0x021C6580 1. PDPTEi 寄存器的值因此 PDPTE2 的值为 0x0000000035AED001 2.

27 4.4.2 页式映射过程程序给出临时变量 tmp 的地址是 0xBF820B90, 将其以二进制表示为 ( 高 2bit 中间 9bit 中间 9bit 最后 12bit) 高 2bit 用来选择 PDPTEi 寄存器,PDPTEi 寄存器的内容是存放在内存中的共有 4 个 PDPTE 寄存器, 组成 PDPTE 表, 物理起始地址在 CR3 寄存器中 CR3 寄存器值为 0x021C PDPTEi 寄存器的值因此 PDPTE2 的值为 0x AED 页面目录表的起始地址 PDPTE2 的值为 0x AED001, 因此页面目录表的起始物理物理为 0x35AED 页面表的地址 0x35AED b*8 = 0x35AEDFE0, 即页面表的物理地址存放在 0x35AEDFE0 地址处页面表项的物理地址为 0x6716B000

4. 页面表项值页面表项的值就是 tmp 变量所在物理页面的起始地址我们来看一下页面表项的值 0x6716B000 + 000100000b*8 = 0x6716B100 该物理地址处的内容为 0x800000007C9EC067 5.

28 4. 页面表项值页面表项的值就是 tmp 变量所在物理页面的起始地址我们来看一下页面表项的值 0x6716B b*8 = 0x6716B100 该物理地址处的内容为 0x C9EC 物理页面地址和 tmp 变量物理地址计算 tmp 变量所在物理页面起始地址为 0x7C9EC000 因此 tmp 变量所在物理地址为 : 0x7C9EC b = 0x7C9ECB90 我们来验证一下物理地址 0x7C9ECB90 存放的数据是什么物理地址 0x7C9ECB90 存放的数据确实是 0x , 和我们代码中赋值一致至此, 我们完整地验证了 32 位系统中 PAE 机制下的地址映射过程 5 常见问题及解答 1 每个用户现在进行地址转换的的时候, 查询的那个页目录表和页表, 是存在内核空间还是用户空间? 这些表是所有用户进程共享的, 还是独立的? 答 : 页面目录表和页表都是存放在物理内存中的, 在内核空间才能访问, 不在用户空间用户进程的页面表是独立的

29 2 页面表的映射关系, 是在装载器 loader 文件到内存的时候动态分配的吗? 答 : 页面表是进程创建时, 内核就会分配相应的页面表当进程访问物理内存时, 内核填充相应的页面表项 3 页面映射关系表只有用户线程才有吧, 内核线程也有这个表吗, 还是直接 -pageoffset 就算出来了? 答 : 不管是内核还是用户态, 都要必须遵守 CPU 架构的地址映射模型内核进程寻址也是完整地进行了段页式地址转换的, 不过最终转换的结果刚好就是 -page_offset 附实验源码下载地址 : /files/memory_address_mapping.tar.bz2

提纲. 1 实验准备. 2 从实模式进入保护模式. 3 小结陈香兰 ( 中国科学技术大学计算机学院 ) 软件综合实验之操作系统 July 1, / 11

.. 软件综合实验之操作系统进入保护模式陈香兰中国科学技术大学计算机学院 July 1, 2016 陈香兰 ( 中国科学技术大学计算机学院 ) 软件综合实验之操作系统 July 1, 2016 1 / 11 提纲. 1 实验准备. 2 从实模式进入保护模式. 3 小结陈香兰 ( 中国科学技术大学计算机学院 ) 软件综合实验之操作系统 July 1, 2016 2 / 11 实验准备实验环境准备

目录 1 概述 IA-32 体系结构内存地址映射 CPU 相关寄存器 系统寄存器 内存管理寄存器 保护模式的内存管理 位时页面机制地址映射 逻辑地址到线性地址的映射...9

目录 1 概述 IA-32 体系结构内存地址映射 CPU 相关寄存器系统寄存器内存管理寄存器保护模式的内存管理位时页面机制地址映射逻辑地址到线性地址的映射...9