拿到这本《程序员的自我修养》之后我一直把它当“厕所读物”在翻结果翻到第六章《可执行文件的装载与进程》时我彻底坐不住了前面几章讲编译、链接还都是静态的文件变换到了这一章文件突然“活”了变成了一个正在跑的进程。这种从死到活的过程恰恰是很多人学了多年编程依然说不清楚的部分。这一章我前后读了两遍半第一遍读得迷迷糊糊第二遍边读边配合实际观测才真正品出味道。如果你正准备面试、想搞懂调试器里那些地址数字到底是什么或者开始接触逆向、底层优化、容器安全第六章绝对值得认真啃。这篇心得不是课本内容的复述而是我读完以后结合实测和踩坑的一次复盘重点聚焦在“装载”这条主线上。梳理清楚这一层再看动态链接、线程模型、沙箱机制都会顺很多。1. 装载到底在解决什么问题为什么值得单开一章1.1 文件是死的进程是活的我们平时写代码脑子里想的是“源代码、编译、链接、生成可执行文件”。可执行文件本质上就是一个保存在磁盘上的字节序列就算它里面指令再完整它也是静态的。可一旦你把它启动成进程事情就变了进程有自己的虚拟地址空间、有自己的栈、有自己的堆、有各种运行时状态CPU 会去它的代码段里一条一条取指令执行。从“磁盘上的文件”变成“内存里的进程”中间这个转换动作就是装载loading。这听起来好像只是“把文件复制到内存里”但真实情况远没有这么简单。一个典型 ELF 可执行文件里代码段是只读可执行的数据段是可读可写的还有一些数据在文件里根本没存比如 .bss 段而是要等到装载时被清零初始化。如果把整个文件从头到尾复制到内存再给所有内存区域都分配物理页那启动一个程序会慢得吓人物理内存也根本不够用。现代操作系统完全不这么干。它采用的办法是“映射 按需分页”装载的时候不急着把文件内容真的搬进物理内存而是先在进程的虚拟地址空间里把“哪块区域对应文件的哪个部分”这个关系登记好等 CPU 真正访问到某个地址时再通过缺页异常把对应的页从磁盘读进来。这个设计是整个现代操作系统的地基第六章讲装载其实就是在讲这块地基是怎么打的。1.2 从虚拟地址空间这张“户型图”说起要理解装载必须先理解进程的虚拟地址空间长什么样。以最常见的 64 位 Linux 为例一个用户态进程的地址空间大致是这样一个布局代码段和只读数据驻留在较低的地址往上依次是数据段、BSS 段、堆heap、内存映射区mmap 区再往上是一大块留给共享库和动态链接器的区域而最高处是栈stack、参数和环境变量区。再往上更高位的地址就是内核空间了用户态程序碰不到。这就像一套房子的户型图代码段是厨房规定只能看不能动数据段是客厅可以随意摆放家具堆是储物间动态分配的东西住在那里栈是走廊函数调用时进进出出。我第一次把这些区域排到一起时突然就理解了为什么调试器里显示的地址都是“一堆奇怪的数”。比如栈地址通常在0x7fff...这种极高的位置而普通可执行文件代码段往往在0x400000附近。这不是随机定的而是操作系统为了让每个程序都能在自己稳定的“户型”里运行特意做的统一规划。弄懂这张户型图是读懂第六章所有后续内容的前提。你只有知道地址空间里有哪几块地才知道 ELF 文件里的各个段分别要往哪块地安家。2. 装载之前先读懂 ELF 里的“两套地图”2.1 节Section和段Segment链接器的清单 vs 装载器的地图读这一章时最容易被绕晕的就是 ELF 文件里同时存在两个“表”节表section header table和段表program header table也就是程序头表。为什么需要两套节表是给链接器看的。链接器视角下文件内容按功能划分.text放代码.data放已初始化数据.rodata放只读常量.bss放未初始化数据.debug放调试信息等等。这些小节记录的是文件的“内部组织结构”方便链接器进行符号解析和重定位。段表是给装载器操作系统内核看的。装载器不关心文件里有多少种节它只关心一件事哪些数据要放进内存、放进内存后允许哪些权限。所以它会做一次“打包”把多个相邻的、权限要求相似的节合并成一个段Segment装载时以段为单位进行映射。打个比方节表是一张行李清单列了“衣服、牙刷、充电器、雨伞”段表是装箱后的标签上面写着“第一箱怕压易碎品轻拿轻放第二箱不怕摔的衣物随便扔”。典型情况下一个简单可执行文件会被合并成两三个PT_LOAD段段包含内容权限装载属性第一个 LOAD 段ELF 头 .text.rodata可读可执行直接映射文件内容第二个 LOAD 段可选.data.bss可读可写文件内容映射后多出部分清零第三个 LOAD 段动态库场景.dynamic/.got/.plt可读可写留给动态链接器处理提示不同编译器、不同链接脚本产出的段划分会有差异。不要把“一定是两段”记死要会用工具去看实际的段表这是后文实操部分的核心技能。2.2 程序头表里的字段装载器的“施工图纸”在 ELF 文件里程序头表Program Header Table是装载器直接读取的数据结构。每个程序头条目里有一堆关键字段学习时千万别跳过p_type段的类型。PT_LOAD表示这是一个需要被装载到内存的段PT_INTERP表示动态链接器的路径PT_DYNAMIC表示动态链接信息PT_PHDR表示程序头表自身的位置。p_offset该段内容在文件中的起始偏移。p_vaddr该段内容要装载到的虚拟地址。p_filesz该段在文件里占用的字节数。p_memsz该段在内存里占用的字节数。p_flags内存权限标志可读R、可写W、可执行X。p_align对齐方式通常是页大小0x1000。这中间最核心的换算关系是对于任意一个段文件偏移和虚拟地址是可以互相换算的虚拟地址 段虚拟地址起点 (文件偏移 - 段文件偏移起点)举个例子如果某个PT_LOAD段满足p_offset 0x1000、p_vaddr 0x400000那么文件偏移0x1000处的字节会被放到虚拟地址0x400000处。于是0x2000处的字节对应虚拟地址0x401000以此类推。可别小看这个公式。后面很多实战场景都要用到它解析 core dump、做符号定位、分析崩溃日志里某个地址对应文件哪个位置靠的都是这个换算。理解它你才算真正看懂 ELF。另一个容易忽略的字段是p_filesz和p_memsz不一致的问题。常见的PT_LOAD段里如果p_memsz比p_filesz大说明这个段在内存里比在文件里多了一块区域多的那部分通常就是.bss段装载时系统会自动把这部分清零。所以.bss在磁盘上不占空间但在进程地址空间里实实在在占了地方。3. 一次装载的完整旅程从内核视角看 ELF 如何“安家”3.1 敲下回车后内核做了什么我们在终端里输入./hello并回车实际上是调用了execve这个系统调用。从这一刻起内核就扮演起了“搬家公司”的角色整个过程大致分五步。第一步内核根据路径找到文件读取 ELF 头。它会先校验文件开头的几个魔数确认这确实是一个 ELF 文件再读取e_type确认它是可执行文件而不是可重定位文件或共享对象接着从 ELF 头里取到入口点e_entry、程序头表偏移e_phoff、程序头数量e_phnum。第二步内核按e_phoff指向的位置读取整个程序头表。程序头表里可能同时存在很多非PT_LOAD类型的条目比如PT_INTERP、PT_DYNAMIC。对PT_LOAD类型的条目内核会逐个建立虚拟地址区间映射。这里有一个容易被忽略的细节为了效率内核做映射时不是严格按照p_vaddr一个字节一个字节来而是会对齐到页边界。也就是说如果某段的p_vaddr是0x400208内核实际从0x400000就开始建立映射只是页内的那些多出来空间对应的是 ELF 文件偏移 0 处的内容通常是 ELF 头。第三步对每个PT_LOAD段内核以MAP_PRIVATE的方式映射文件中的[p_offset, p_offset p_filesz)区域到地址[p_vaddr, p_vaddr p_filesz)。而对p_memsz大于p_filesz的部分也就是.bss区域内核不会从文件里读而是直接在内存中清零。这个过程说快也快因为大部分操作只是在修改进程的页表和地址空间描述符真正的磁盘读取被推迟到之后访问时才发生。第四步内核为进程准备好初始的栈。这个栈上不只是“栈”那么简单它还承载了命令行参数argv、环境变量envp以及一组被称为 auxiliary vector辅助向量的数据。比如AT_PHDR告诉程序程序头表在哪AT_ENTRY告诉程序最终入口在哪AT_BASE告诉程序动态链接器被加载到了哪个基地址。_start汇编代码能够正确跳转并且获取参数靠的就是这块精心布置的栈区。第五步设置 CPU 的指令指针寄存器把控制权交给程序的入口。这个入口不一定最终就是我们 main 函数对应的地址而是_start一个由 C 运行时库提供的启动代码。_start完成堆栈对齐、初始化 libc、调用 main最后在 main 返回时调用 exit。3.2 动态链接器的登场装载过程的第一次“换手”上面说“把控制权交给入口”这在静态链接的程序里是对的。但对于绝大多数动态链接的程序内核其实不会直接跳到 ELF 头里的e_entry而是会先看一下程序头表里有没有PT_INTERP条目。PT_INTERP里存的通常是一个字符串指向动态链接器也叫解释器的路径常见的是ld-linux-x86-64.so.2这样的名字。如果存在这个条目内核会把动态链接器自身也映射进地址空间然后把控制权先交给动态链接器的入口而不是主程序的入口。动态链接器的任务非常重它要读取主程序的PT_DYNAMIC信息找到依赖的共享库列表DT_NEEDED逐个把共享库装载进来并解析它们之间的依赖关系还要处理各种重定位包括 GOT 表、PLT 表的修复最后一切就绪了才通过一个跳转把控制权交还给主程序的_start。这个过程在书里往往是“上”部分最后一屏的内容因为它和动态链接是紧紧咬合在一起的。装载和动态链接并不是先后完全分开的两个阶段装载阶段时内核已为动态链接器做了特殊准备动态链接器运行过程中又会不断产生新的装载动作映射共享库、匿名映射。所以理解装载也是在给理解动态链接打基础。3.3 bss 段的特殊待遇文件里没有它进程里不能少它很多人第一次看到.bss会有困惑未初始化的全局变量在文件里到底存不存在答案是不存在。在链接后的可执行文件里.bss不会占用文件空间。真正体现它存在的地方是段表里的p_memsz当p_memsz p_filesz时多出来的那一段就是需要清零的内存区。拿一个典型的第三个LOAD段来说假设它的文件大小只有 0x200 字节但内存大小是 0x400 字节说明这个段有 0x200 字节的内容来自文件.data另外 0x200 字节由装载器清零生成.bss。这样设计的好处很明显一个几百 KB 的全局数组如果在文件里全存零浪费磁盘改成只记录大小、装载时再清零代价只是一次内存初始化。不过这种“懒”也埋了一个坑很多人在分析 core dump 或者程序崩溃现场时会困惑为什么某个地址明明没有对应的文件偏移却能正常访问。其实那就是 bss 段或者栈、堆等匿名映射区域。记住这条规律ELF 文件里的映射对应文件内容文件之外的地址空间部分对应清零初始化的运行数据。4. 自己动手观察“装载现场”几个必会的小实验4.1 先用 readelf 看清段表纸上得来终觉浅装载这件事必须亲眼看一次才记得住。第一步我们可以拿一个最简单的 C 程序编译成可执行文件然后用readelf -l看它的程序头表。gcc -o hello hello.c readelf -l hello你会看到类似这样的输出不同系统略有差异Elf file type is EXEC (Executable file) Entry point 0x401030 There are 13 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0x0000000000400040 0x0000000000400040 0x00000000000002d8 0x00000000000002d8 R 0x8 INTERP 0x0000000000000318 0x0000000000400318 0x0000000000400318 0x000000000000001c 0x000000000000001c R 0x1 [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2] LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000 0x00000000000005a8 0x00000000000005a8 R 0x1000 LOAD 0x0000000000001000 0x0000000000401000 0x0000000000401000 0x0000000000001d5d 0x0000000000001d5d R E 0x1000 LOAD 0x0000000000003000 0x0000000000403000 0x0000000000403000 0x0000000000000168 0x0000000000000168 R 0x1000 LOAD 0x0000000000004000 0x0000000000404000 0x0000000000404000 0x00000000000000e8 0x0000000000000250 RW 0x1000 ...这段输出信息量很大。先看INTERP它告诉我们这是一个动态链接的程序解释器路径明确写在里面。再看LOAD段第一个 LOAD 段是R权限负责把 ELF 头和.rodata等只读内容映射进来第二个 LOAD 段是R E也就是可读、可执行这是代码段.text第三个 LOAD 段权限是R通常放只读数据第四个 LOAD 段权限是RW注意它的FileSiz是 0xe8而MemSiz是 0x250中间的差值 0x168 字节就是.bss段在磁盘上不占空间。看到这个输出前面讲的所有概念就串起来了。4.2 用 /proc/ /maps 看进程运行时的地址空间静态的段表只是“施工图纸”真正“装修完成”后的样子要看进程运行时的地址空间。Linux 下最直观的办法是查看/proc文件系统./hello cat /proc/$!/maps输出大致是这样的00400000-00401000 r--p 00000000 08:01 123456 /tmp/hello 00401000-00402000 r-xp 00001000 08:01 123456 /tmp/hello 00402000-00403000 r--p 00002000 08:01 123456 /tmp/hello 00403000-00404000 r--p 00002000 08:01 123456 /tmp/hello 00404000-00405000 rw-p 00003000 08:01 123456 /tmp/hello ... 7ffd6c800000-7ffd6ca21000 rw-p 00000000 00:00 0 [stack]第一列是虚拟地址范围第二列是权限第三列是相对文件头的偏移最后一列是对应文件或被匿名映射的名字。你可以清楚地看到代码段以r-xp出现说明它是可读可执行但不可写数据段以rw-p出现说明它是可读可写但不可执行同一个可执行文件在地址空间里有多个不连续的映射区间正好对应程序头表里的多个 LOAD 段最上面一路飙升到0x7ffd...的高位区域是栈它是匿名映射没有对应文件。有个细节值得注意很多同学以为权限会直接是r-x、rw-但/proc/maps里最后多出的那个p表示“私有映射”private对应装载时的MAP_PRIVATE。这个私有性是实现“同一个可执行文件可以跑多个互不干扰的进程”的关键。4.3 用系统调用跟踪工具验证装载过程如果想看内核从哪个文件开始加载、加载时传了哪些路径可以用系统调用跟踪工具比如stracestrace -f -e traceexecve ./hello输出会显示execve(./hello, ...)以及后续动态链接器触发的execve或各种mmap调用。虽然execve只有一个但你会看到它后面跟着一长串的mmap这些mmap就是动态链接器在装载共享库时发出的。把这些实际输出和书本内容对照着看我强烈建议你也试一次。这一步一旦完成很多概念就不再是抽象术语而是变成“我亲眼见过的某个地址区间”。注意使用strace时如果程序里包含大量动态库或者其他启动逻辑输出可能会很吓人。建议先用最小程序加-e tracemmap,execve这类过滤条件再分析。5. 学习这一章时最容易踩的坑5.1 坑一把“装载”理解成“把文件全部读进内存”我刚学的时候犯过这个错误以为 exec 之后整个可执行文件就被复制进内存了。后来看/proc/maps才发现映射建立后很多路径根本没有对应物理页甚至加载一个大型可执行文件的速度快得惊人就是因为它压根没读完整内容。实际上Linux 采用的是按需分页demand paging。映射建立时只是设置了虚拟地址到文件页的对应关系物理页要等到 CPU 真正访问到某个地址、触发缺页异常时才从磁盘读入。这也是为什么程序启动可能很快但当它第一次把大量代码页都执行一遍时你会感觉到一点卡顿那正是缺页读盘的过程。理解这一点后再看“为什么一个进程占用虚拟内存很大但物理内存占用却不大”就会非常清晰虚拟地址空间只是一个地址计划物理页才是真正花出去的钱。5.2 坑二把节Section和段Segment混为一谈这一章核心概念里最容易混淆的就是 Section 和 Segment。我不止一次看到有人在讨论时说“ELF 的 text 段”又把段表和节表混用在同一个语境里。更准确的说法是ELF 文件里有多个 Section节装载器把它合并成多个 Segment段。节表是编译链接期的概念程序头表段表是运行装载期的概念。分析一个二进制时如果目标是看运行时地址和权限就看程序头表如果目标是看符号、调试信息、重定位就看节表。5.3 坑三只读段被装进可读可执行段带来的权限放大问题细心看readelf -l的输出你会注意到 ELF 头、.rodata有时会和代码段合并成一个R E的 LOAD 段这意味着只读数据所在的页面同时具有可执行权限。从安全和 DEP数据执行保护的角度看这是一个不太理想的状态因为如果在这些只读数据里注入代码CPU 也允许执行它。现代工具链已经在改善这个问题。新的编译器版本默认会对只读数据和代码做更细的划分甚至单独拆出一个R权限的 LOAD 段。但历史二进制和老旧的链接脚本里这种权限放大依然很常见。理解这个现象后再去看某些安全加固方案例如-z separate-code在做什么思路就会打开。5.4 常见问题速查现象原因排查方法可执行文件很大但启动很快按需分页未真正读入所有页/proc/pid/maps 观察 RSS运行时地址和 readelf 里的 Vaddr 不一致ASLR 随机化或动态装载基址变化对比setarch -R关闭随机化后的结果bss 全局变量在 core dump 里是零.bss在文件中不存在运行期清零检查段表的FileSiz与MemSiz两个进程跑同一个程序地址空间看起来一样虚拟地址空间独立物理页可共享看/proc/pid/pagemap或对比物理页/proc/maps里同个文件出现多个区间一个文件的多个 LOAD 段被分别映射对照readelf -l的 LOAD 段偏移每条我都实际碰到过尤其是 ASLR 那条。第一次在调试器里看到共享库每次加载地址都不同我还以为是系统坏了。后来才知道这是默认开启的地址空间随机化防止攻击者猜测固定跳转目标。这也反向说明装载过程是一个动态适配的过程不是死板地照着 ELF 头抄一遍。6. 个人体会把这一章“装进脑子里”的笨办法这一章内容不算多但信息密度很高。我读完第一遍时感觉每个字都认识合上书却什么都讲不出来。后来我换了种学法用三个问题逼自己复盘程序从哪里开始ELF 文件凭什么能被映射内核和动态链接器如何在装载中交接如果你也卡在这一章我给一个最笨但最有效的建议找一台 Linux 机器编译一个最小 C 程序从readelf -l开始把段表每一项对着/proc/pid/maps看一遍再用strace观察整个启动过程中的系统调用。这个过程花不了半小时但对知识的固化效果顶得上反复看书好几遍。我还记得自己第一次把地址空间里每个区间和readelf里的段一一对上号时的那种通透感原来操作系统不是“搬运工”而更像是一个“房产中介”——它不动你的家具但帮你划好地界、贴好标签等你真正搬进去住的那一刻才把必要的资源送到位。装载只是进程“前半生”的开始。接下来动态链接、重定位、进程运行的细节还会不断把这张地址空间的大网织得更密。带着这一章的底子往下看你会发现自己已经能回答很多“看起来很高深”的问题了。
拿到这本《程序员的自我修养》之后我一直把它当“厕所读物”在翻结果翻到第六章《可执行文件的装载与进程》时我彻底坐不住了前面几章讲编译、链接还都是静态的文件变换到了这一章文件突然“活”了变成了一个正在跑的进程。这种从死到活的过程恰恰是很多人学了多年编程依然说不清楚的部分。这一章我前后读了两遍半第一遍读得迷迷糊糊第二遍边读边配合实际观测才真正品出味道。如果你正准备面试、想搞懂调试器里那些地址数字到底是什么或者开始接触逆向、底层优化、容器安全第六章绝对值得认真啃。这篇心得不是课本内容的复述而是我读完以后结合实测和踩坑的一次复盘重点聚焦在“装载”这条主线上。梳理清楚这一层再看动态链接、线程模型、沙箱机制都会顺很多。1. 装载到底在解决什么问题为什么值得单开一章1.1 文件是死的进程是活的我们平时写代码脑子里想的是“源代码、编译、链接、生成可执行文件”。可执行文件本质上就是一个保存在磁盘上的字节序列就算它里面指令再完整它也是静态的。可一旦你把它启动成进程事情就变了进程有自己的虚拟地址空间、有自己的栈、有自己的堆、有各种运行时状态CPU 会去它的代码段里一条一条取指令执行。从“磁盘上的文件”变成“内存里的进程”中间这个转换动作就是装载loading。这听起来好像只是“把文件复制到内存里”但真实情况远没有这么简单。一个典型 ELF 可执行文件里代码段是只读可执行的数据段是可读可写的还有一些数据在文件里根本没存比如 .bss 段而是要等到装载时被清零初始化。如果把整个文件从头到尾复制到内存再给所有内存区域都分配物理页那启动一个程序会慢得吓人物理内存也根本不够用。现代操作系统完全不这么干。它采用的办法是“映射 按需分页”装载的时候不急着把文件内容真的搬进物理内存而是先在进程的虚拟地址空间里把“哪块区域对应文件的哪个部分”这个关系登记好等 CPU 真正访问到某个地址时再通过缺页异常把对应的页从磁盘读进来。这个设计是整个现代操作系统的地基第六章讲装载其实就是在讲这块地基是怎么打的。1.2 从虚拟地址空间这张“户型图”说起要理解装载必须先理解进程的虚拟地址空间长什么样。以最常见的 64 位 Linux 为例一个用户态进程的地址空间大致是这样一个布局代码段和只读数据驻留在较低的地址往上依次是数据段、BSS 段、堆heap、内存映射区mmap 区再往上是一大块留给共享库和动态链接器的区域而最高处是栈stack、参数和环境变量区。再往上更高位的地址就是内核空间了用户态程序碰不到。这就像一套房子的户型图代码段是厨房规定只能看不能动数据段是客厅可以随意摆放家具堆是储物间动态分配的东西住在那里栈是走廊函数调用时进进出出。我第一次把这些区域排到一起时突然就理解了为什么调试器里显示的地址都是“一堆奇怪的数”。比如栈地址通常在0x7fff...这种极高的位置而普通可执行文件代码段往往在0x400000附近。这不是随机定的而是操作系统为了让每个程序都能在自己稳定的“户型”里运行特意做的统一规划。弄懂这张户型图是读懂第六章所有后续内容的前提。你只有知道地址空间里有哪几块地才知道 ELF 文件里的各个段分别要往哪块地安家。2. 装载之前先读懂 ELF 里的“两套地图”2.1 节Section和段Segment链接器的清单 vs 装载器的地图读这一章时最容易被绕晕的就是 ELF 文件里同时存在两个“表”节表section header table和段表program header table也就是程序头表。为什么需要两套节表是给链接器看的。链接器视角下文件内容按功能划分.text放代码.data放已初始化数据.rodata放只读常量.bss放未初始化数据.debug放调试信息等等。这些小节记录的是文件的“内部组织结构”方便链接器进行符号解析和重定位。段表是给装载器操作系统内核看的。装载器不关心文件里有多少种节它只关心一件事哪些数据要放进内存、放进内存后允许哪些权限。所以它会做一次“打包”把多个相邻的、权限要求相似的节合并成一个段Segment装载时以段为单位进行映射。打个比方节表是一张行李清单列了“衣服、牙刷、充电器、雨伞”段表是装箱后的标签上面写着“第一箱怕压易碎品轻拿轻放第二箱不怕摔的衣物随便扔”。典型情况下一个简单可执行文件会被合并成两三个PT_LOAD段段包含内容权限装载属性第一个 LOAD 段ELF 头 .text.rodata可读可执行直接映射文件内容第二个 LOAD 段可选.data.bss可读可写文件内容映射后多出部分清零第三个 LOAD 段动态库场景.dynamic/.got/.plt可读可写留给动态链接器处理提示不同编译器、不同链接脚本产出的段划分会有差异。不要把“一定是两段”记死要会用工具去看实际的段表这是后文实操部分的核心技能。2.2 程序头表里的字段装载器的“施工图纸”在 ELF 文件里程序头表Program Header Table是装载器直接读取的数据结构。每个程序头条目里有一堆关键字段学习时千万别跳过p_type段的类型。PT_LOAD表示这是一个需要被装载到内存的段PT_INTERP表示动态链接器的路径PT_DYNAMIC表示动态链接信息PT_PHDR表示程序头表自身的位置。p_offset该段内容在文件中的起始偏移。p_vaddr该段内容要装载到的虚拟地址。p_filesz该段在文件里占用的字节数。p_memsz该段在内存里占用的字节数。p_flags内存权限标志可读R、可写W、可执行X。p_align对齐方式通常是页大小0x1000。这中间最核心的换算关系是对于任意一个段文件偏移和虚拟地址是可以互相换算的虚拟地址 段虚拟地址起点 (文件偏移 - 段文件偏移起点)举个例子如果某个PT_LOAD段满足p_offset 0x1000、p_vaddr 0x400000那么文件偏移0x1000处的字节会被放到虚拟地址0x400000处。于是0x2000处的字节对应虚拟地址0x401000以此类推。可别小看这个公式。后面很多实战场景都要用到它解析 core dump、做符号定位、分析崩溃日志里某个地址对应文件哪个位置靠的都是这个换算。理解它你才算真正看懂 ELF。另一个容易忽略的字段是p_filesz和p_memsz不一致的问题。常见的PT_LOAD段里如果p_memsz比p_filesz大说明这个段在内存里比在文件里多了一块区域多的那部分通常就是.bss段装载时系统会自动把这部分清零。所以.bss在磁盘上不占空间但在进程地址空间里实实在在占了地方。3. 一次装载的完整旅程从内核视角看 ELF 如何“安家”3.1 敲下回车后内核做了什么我们在终端里输入./hello并回车实际上是调用了execve这个系统调用。从这一刻起内核就扮演起了“搬家公司”的角色整个过程大致分五步。第一步内核根据路径找到文件读取 ELF 头。它会先校验文件开头的几个魔数确认这确实是一个 ELF 文件再读取e_type确认它是可执行文件而不是可重定位文件或共享对象接着从 ELF 头里取到入口点e_entry、程序头表偏移e_phoff、程序头数量e_phnum。第二步内核按e_phoff指向的位置读取整个程序头表。程序头表里可能同时存在很多非PT_LOAD类型的条目比如PT_INTERP、PT_DYNAMIC。对PT_LOAD类型的条目内核会逐个建立虚拟地址区间映射。这里有一个容易被忽略的细节为了效率内核做映射时不是严格按照p_vaddr一个字节一个字节来而是会对齐到页边界。也就是说如果某段的p_vaddr是0x400208内核实际从0x400000就开始建立映射只是页内的那些多出来空间对应的是 ELF 文件偏移 0 处的内容通常是 ELF 头。第三步对每个PT_LOAD段内核以MAP_PRIVATE的方式映射文件中的[p_offset, p_offset p_filesz)区域到地址[p_vaddr, p_vaddr p_filesz)。而对p_memsz大于p_filesz的部分也就是.bss区域内核不会从文件里读而是直接在内存中清零。这个过程说快也快因为大部分操作只是在修改进程的页表和地址空间描述符真正的磁盘读取被推迟到之后访问时才发生。第四步内核为进程准备好初始的栈。这个栈上不只是“栈”那么简单它还承载了命令行参数argv、环境变量envp以及一组被称为 auxiliary vector辅助向量的数据。比如AT_PHDR告诉程序程序头表在哪AT_ENTRY告诉程序最终入口在哪AT_BASE告诉程序动态链接器被加载到了哪个基地址。_start汇编代码能够正确跳转并且获取参数靠的就是这块精心布置的栈区。第五步设置 CPU 的指令指针寄存器把控制权交给程序的入口。这个入口不一定最终就是我们 main 函数对应的地址而是_start一个由 C 运行时库提供的启动代码。_start完成堆栈对齐、初始化 libc、调用 main最后在 main 返回时调用 exit。3.2 动态链接器的登场装载过程的第一次“换手”上面说“把控制权交给入口”这在静态链接的程序里是对的。但对于绝大多数动态链接的程序内核其实不会直接跳到 ELF 头里的e_entry而是会先看一下程序头表里有没有PT_INTERP条目。PT_INTERP里存的通常是一个字符串指向动态链接器也叫解释器的路径常见的是ld-linux-x86-64.so.2这样的名字。如果存在这个条目内核会把动态链接器自身也映射进地址空间然后把控制权先交给动态链接器的入口而不是主程序的入口。动态链接器的任务非常重它要读取主程序的PT_DYNAMIC信息找到依赖的共享库列表DT_NEEDED逐个把共享库装载进来并解析它们之间的依赖关系还要处理各种重定位包括 GOT 表、PLT 表的修复最后一切就绪了才通过一个跳转把控制权交还给主程序的_start。这个过程在书里往往是“上”部分最后一屏的内容因为它和动态链接是紧紧咬合在一起的。装载和动态链接并不是先后完全分开的两个阶段装载阶段时内核已为动态链接器做了特殊准备动态链接器运行过程中又会不断产生新的装载动作映射共享库、匿名映射。所以理解装载也是在给理解动态链接打基础。3.3 bss 段的特殊待遇文件里没有它进程里不能少它很多人第一次看到.bss会有困惑未初始化的全局变量在文件里到底存不存在答案是不存在。在链接后的可执行文件里.bss不会占用文件空间。真正体现它存在的地方是段表里的p_memsz当p_memsz p_filesz时多出来的那一段就是需要清零的内存区。拿一个典型的第三个LOAD段来说假设它的文件大小只有 0x200 字节但内存大小是 0x400 字节说明这个段有 0x200 字节的内容来自文件.data另外 0x200 字节由装载器清零生成.bss。这样设计的好处很明显一个几百 KB 的全局数组如果在文件里全存零浪费磁盘改成只记录大小、装载时再清零代价只是一次内存初始化。不过这种“懒”也埋了一个坑很多人在分析 core dump 或者程序崩溃现场时会困惑为什么某个地址明明没有对应的文件偏移却能正常访问。其实那就是 bss 段或者栈、堆等匿名映射区域。记住这条规律ELF 文件里的映射对应文件内容文件之外的地址空间部分对应清零初始化的运行数据。4. 自己动手观察“装载现场”几个必会的小实验4.1 先用 readelf 看清段表纸上得来终觉浅装载这件事必须亲眼看一次才记得住。第一步我们可以拿一个最简单的 C 程序编译成可执行文件然后用readelf -l看它的程序头表。gcc -o hello hello.c readelf -l hello你会看到类似这样的输出不同系统略有差异Elf file type is EXEC (Executable file) Entry point 0x401030 There are 13 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0x0000000000400040 0x0000000000400040 0x00000000000002d8 0x00000000000002d8 R 0x8 INTERP 0x0000000000000318 0x0000000000400318 0x0000000000400318 0x000000000000001c 0x000000000000001c R 0x1 [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2] LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000 0x00000000000005a8 0x00000000000005a8 R 0x1000 LOAD 0x0000000000001000 0x0000000000401000 0x0000000000401000 0x0000000000001d5d 0x0000000000001d5d R E 0x1000 LOAD 0x0000000000003000 0x0000000000403000 0x0000000000403000 0x0000000000000168 0x0000000000000168 R 0x1000 LOAD 0x0000000000004000 0x0000000000404000 0x0000000000404000 0x00000000000000e8 0x0000000000000250 RW 0x1000 ...这段输出信息量很大。先看INTERP它告诉我们这是一个动态链接的程序解释器路径明确写在里面。再看LOAD段第一个 LOAD 段是R权限负责把 ELF 头和.rodata等只读内容映射进来第二个 LOAD 段是R E也就是可读、可执行这是代码段.text第三个 LOAD 段权限是R通常放只读数据第四个 LOAD 段权限是RW注意它的FileSiz是 0xe8而MemSiz是 0x250中间的差值 0x168 字节就是.bss段在磁盘上不占空间。看到这个输出前面讲的所有概念就串起来了。4.2 用 /proc/ /maps 看进程运行时的地址空间静态的段表只是“施工图纸”真正“装修完成”后的样子要看进程运行时的地址空间。Linux 下最直观的办法是查看/proc文件系统./hello cat /proc/$!/maps输出大致是这样的00400000-00401000 r--p 00000000 08:01 123456 /tmp/hello 00401000-00402000 r-xp 00001000 08:01 123456 /tmp/hello 00402000-00403000 r--p 00002000 08:01 123456 /tmp/hello 00403000-00404000 r--p 00002000 08:01 123456 /tmp/hello 00404000-00405000 rw-p 00003000 08:01 123456 /tmp/hello ... 7ffd6c800000-7ffd6ca21000 rw-p 00000000 00:00 0 [stack]第一列是虚拟地址范围第二列是权限第三列是相对文件头的偏移最后一列是对应文件或被匿名映射的名字。你可以清楚地看到代码段以r-xp出现说明它是可读可执行但不可写数据段以rw-p出现说明它是可读可写但不可执行同一个可执行文件在地址空间里有多个不连续的映射区间正好对应程序头表里的多个 LOAD 段最上面一路飙升到0x7ffd...的高位区域是栈它是匿名映射没有对应文件。有个细节值得注意很多同学以为权限会直接是r-x、rw-但/proc/maps里最后多出的那个p表示“私有映射”private对应装载时的MAP_PRIVATE。这个私有性是实现“同一个可执行文件可以跑多个互不干扰的进程”的关键。4.3 用系统调用跟踪工具验证装载过程如果想看内核从哪个文件开始加载、加载时传了哪些路径可以用系统调用跟踪工具比如stracestrace -f -e traceexecve ./hello输出会显示execve(./hello, ...)以及后续动态链接器触发的execve或各种mmap调用。虽然execve只有一个但你会看到它后面跟着一长串的mmap这些mmap就是动态链接器在装载共享库时发出的。把这些实际输出和书本内容对照着看我强烈建议你也试一次。这一步一旦完成很多概念就不再是抽象术语而是变成“我亲眼见过的某个地址区间”。注意使用strace时如果程序里包含大量动态库或者其他启动逻辑输出可能会很吓人。建议先用最小程序加-e tracemmap,execve这类过滤条件再分析。5. 学习这一章时最容易踩的坑5.1 坑一把“装载”理解成“把文件全部读进内存”我刚学的时候犯过这个错误以为 exec 之后整个可执行文件就被复制进内存了。后来看/proc/maps才发现映射建立后很多路径根本没有对应物理页甚至加载一个大型可执行文件的速度快得惊人就是因为它压根没读完整内容。实际上Linux 采用的是按需分页demand paging。映射建立时只是设置了虚拟地址到文件页的对应关系物理页要等到 CPU 真正访问到某个地址、触发缺页异常时才从磁盘读入。这也是为什么程序启动可能很快但当它第一次把大量代码页都执行一遍时你会感觉到一点卡顿那正是缺页读盘的过程。理解这一点后再看“为什么一个进程占用虚拟内存很大但物理内存占用却不大”就会非常清晰虚拟地址空间只是一个地址计划物理页才是真正花出去的钱。5.2 坑二把节Section和段Segment混为一谈这一章核心概念里最容易混淆的就是 Section 和 Segment。我不止一次看到有人在讨论时说“ELF 的 text 段”又把段表和节表混用在同一个语境里。更准确的说法是ELF 文件里有多个 Section节装载器把它合并成多个 Segment段。节表是编译链接期的概念程序头表段表是运行装载期的概念。分析一个二进制时如果目标是看运行时地址和权限就看程序头表如果目标是看符号、调试信息、重定位就看节表。5.3 坑三只读段被装进可读可执行段带来的权限放大问题细心看readelf -l的输出你会注意到 ELF 头、.rodata有时会和代码段合并成一个R E的 LOAD 段这意味着只读数据所在的页面同时具有可执行权限。从安全和 DEP数据执行保护的角度看这是一个不太理想的状态因为如果在这些只读数据里注入代码CPU 也允许执行它。现代工具链已经在改善这个问题。新的编译器版本默认会对只读数据和代码做更细的划分甚至单独拆出一个R权限的 LOAD 段。但历史二进制和老旧的链接脚本里这种权限放大依然很常见。理解这个现象后再去看某些安全加固方案例如-z separate-code在做什么思路就会打开。5.4 常见问题速查现象原因排查方法可执行文件很大但启动很快按需分页未真正读入所有页/proc/pid/maps 观察 RSS运行时地址和 readelf 里的 Vaddr 不一致ASLR 随机化或动态装载基址变化对比setarch -R关闭随机化后的结果bss 全局变量在 core dump 里是零.bss在文件中不存在运行期清零检查段表的FileSiz与MemSiz两个进程跑同一个程序地址空间看起来一样虚拟地址空间独立物理页可共享看/proc/pid/pagemap或对比物理页/proc/maps里同个文件出现多个区间一个文件的多个 LOAD 段被分别映射对照readelf -l的 LOAD 段偏移每条我都实际碰到过尤其是 ASLR 那条。第一次在调试器里看到共享库每次加载地址都不同我还以为是系统坏了。后来才知道这是默认开启的地址空间随机化防止攻击者猜测固定跳转目标。这也反向说明装载过程是一个动态适配的过程不是死板地照着 ELF 头抄一遍。6. 个人体会把这一章“装进脑子里”的笨办法这一章内容不算多但信息密度很高。我读完第一遍时感觉每个字都认识合上书却什么都讲不出来。后来我换了种学法用三个问题逼自己复盘程序从哪里开始ELF 文件凭什么能被映射内核和动态链接器如何在装载中交接如果你也卡在这一章我给一个最笨但最有效的建议找一台 Linux 机器编译一个最小 C 程序从readelf -l开始把段表每一项对着/proc/pid/maps看一遍再用strace观察整个启动过程中的系统调用。这个过程花不了半小时但对知识的固化效果顶得上反复看书好几遍。我还记得自己第一次把地址空间里每个区间和readelf里的段一一对上号时的那种通透感原来操作系统不是“搬运工”而更像是一个“房产中介”——它不动你的家具但帮你划好地界、贴好标签等你真正搬进去住的那一刻才把必要的资源送到位。装载只是进程“前半生”的开始。接下来动态链接、重定位、进程运行的细节还会不断把这张地址空间的大网织得更密。带着这一章的底子往下看你会发现自己已经能回答很多“看起来很高深”的问题了。
