---

title: Linux ELF 二进制加载深度实战：从 execve 到动态链接、PLT/GOT 与延迟绑定

category: 编程技术

keywords: Linux,ELF,动态链接,PLT,GOT,延迟绑定,execve,链接器,加载器,二进制分析

description: 深入剖析 Linux ELF 二进制文件的加载与链接全过程，从内核 load_elf_binary 到动态链接器的 _dl_runtime_resolve、PLT/GOT 延迟绑定机制，涵盖静态分析、动态调试、性能优化与安全防护的实战指南

flag: recommend,top

---

Linux ELF 二进制加载深度实战：从 execve 到动态链接、PLT/GOT 与延迟绑定

引言

当你敲下 ./a.out 并按下回车的那一刻，操作系统内部爆发了一场精密的"链式反应"：内核解析 ELF 头部、建立内存映射、加载动态链接器、符号重定位、GOT 表初始化……理解这整个过程，是掌握 Linux 系统编程、性能调优和安全防护的关键基石。

本文将从内核源码级别的视角，一步步追踪一个 ELF 可执行文件从磁盘到 CPU 指令执行的全链路，覆盖 ELF 格式解析、内存布局构建、动态链接的 PLT/GOT 延迟绑定、_dl_runtime_resolve 的符号解析流程，以及生产环境下的 LD_DEBUG、prelink、RELRO 等实用工具与安全加固策略。

第一部分：ELF 文件结构精析

ELF 头部：整个文件的"地图索引"

ELF（Executable and Linkable Format）是 Linux 下最核心的二进制格式，统一了可执行文件、共享库（.so）、目标文件（.o）和核心转储（core dump）。

// /usr/include/elf.h 中的关键字段
typedef struct {
    unsigned char e_ident[16];  // 魔数 + 字长 + 端序 + 版本
    Elf64_Half    e_type;       // ET_EXEC / ET_DYN / ET_REL
    Elf64_Half    e_machine;    // EM_X86_64 / EM_AARCH64
    Elf64_Off     e_entry;      // 程序入口虚拟地址
    Elf64_Off     e_phoff;      // Program Header Table 偏移
    Elf64_Off     e_shoff;      // Section Header Table 偏移
    Elf64_Half    e_phentsize;  // Program Header 单项大小
    Elf64_Half    e_phnum;      // Program Header 数量
} Elf64_Ehdr;

使用 readelf -h 查看一个典型的 x86_64 可执行文件：

$ readelf -h /bin/ls
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2's complement, little endian
  Machine:                           Advanced Micro Devices X86-64
  Type:                              DYN (Position-Independent Executable)
  Entry point address:               0x6a20

关键洞察：现代 GCC 默认生成 PIE（Position-Independent Executable）类型，即 e_type = ET_DYN，即使它是可执行文件而非共享库。这是 ASLR（地址空间布局随机化）的基础。

Program Header 与 Segment 加载

内核加载 ELF 时只关心 Program Header（段视角），忽略 Section Header（节视角，给链接器用的）：

typedef struct {
    Elf64_Word  p_type;    // PT_LOAD / PT_INTERP / PT_PHDR / PT_DYNAMIC
    Elf64_Word  p_flags;   // PF_R / PF_W / PF_X
    Elf64_Off   p_offset;  // 文件内偏移
    Elf64_Addr  p_vaddr;   // 虚拟地址
    Elf64_Xword p_filesz;  // 文件大小
    Elf64_Xword p_memsz;   // 内存大小（可能大于文件大小，.bss 段）
    Elf64_Xword p_align;   // 对齐要求
} Elf64_Phdr;

$ readelf -l /bin/ls

Type    Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg  Align
LOAD    0x000000 0x0000000000000000 0x0000000000000000 0x201e48 0x201e48 R E  0x1000
LOAD    0x0202230 0x00000000000212230 0x00000000000212230 0x00b50  0x00bf8 RW  0x1000
INTERP  0x000318 0x0000000000000318 0x0000000000000318 0x0001c  0x0001c R    0x1
DYNAMIC 0x01ff928 0x0000000000020f928 0x0000000000020f928 0x00480  0x00480 RW   0x8

这里有两个 PT_LOAD 段：第一个是代码段（R+X），第二个是数据段（R+W）。p_memsz > p_filesz 的部分就是 .bss 段（未初始化的全局变量），内核会用 mmap + 零页来填充。

PT_INTERP 段的内容是动态链接器路径：/lib64/ld-linux-x86-64.so.2。

第二部分：内核加载流程 load_elf_binary

从 execve 到 load_elf_binary 的调用链

sys_execve()
  └── do_execve()
       └── do_execveat_common()
            └── bprm_execve()
                 └── exec_binprm()
                      └── search_binary_handler()
                           └── load_elf_binary()   // fs/binfmt_elf.c

内核支持的每种二进制格式通过 register_binfmt() 注册一个 linux_binfmt 结构体，ELF 格式在初始化时通过 fs/binfmt_elf.c 注册。

load_elf_binary 的核心步骤

以下是该函数的关键执行路径：

1. 读取 ELF 头部到内核缓冲区（前 64 字节）
2. 验证魔数：0x7f 'E' 'L' 'F'
3. 检查 e_type（ET_EXEC 或 ET_DYN）
4. 遍历 Program Header：
   a. 根据 PT_LOAD 调用 setup_arg_pages() 设置用户栈
   b. 通过 elf_map() 建立文件到虚拟内存的映射（mmap）
   c. 处理 BSS：memset(0) 填充 p_memsz - p_filesz 区域
5. 如果是动态链接（存在 PT_INTERP）：
   a. 加载动态链接器（ld-linux.so）本身（递归调用 load_elf_binary）
   b. 将入口点设为动态链接器的入口，而非原程序的 _start
6. 设置辅助向量（Auxiliary Vector）：AT_PHDR、AT_PHENT、AT_PHNUM、
   AT_ENTRY、AT_UID、AT_EUID、AT_SYSINFO_EHDR（vDSO 地址）等
7. 调用 start_thread() 设置用户态寄存器（RIP → 入口，RSP → 用户栈顶）

辅助向量（Auxiliary Vector）是内核在用户栈上推入的一组键值对，动态链接器和 C 运行时（glibc）依赖它们来获取运行时信息：

AT_PHDR    = 程序头部表地址（动态链接器用它来计算加载偏移）
AT_PHENT   = 单个程序头部大小
AT_PHNUM   = 程序头部数量
AT_PAGESZ  = 页大小（4096）
AT_BASE    = 动态链接器自身基址
AT_ENTRY   = 原程序入口点（_start）
AT_NULL    = 终止标记

第三部分：动态链接与延迟绑定机制

为什么需要动态链接

静态链接的程序可能只有几十行代码却有几十 MB 体积（因为 glibc 全量链接）。动态链接让多个进程共享同一份物理内存中的共享库代码段（通过 MAP_PRIVATE + 写时复制 Only 数据段各自独立），大幅节省内存。

PLT/GOT 延迟绑定的精髓

延迟绑定（Lazy Binding）是 ELF 动态链接最精妙的设计之一：函数在第一次调用时才解析地址，后续调用直接跳转。

调用链对比：

首次调用 printf：
用户代码 → PLT[n] → GOT[n]（回跳到 PLT[n] 下一条指令）
         → PLT[0]（公共桩） → GOT[1]（链接器结构）
         → _dl_runtime_resolve() → 解析符号 → 写入 GOT[n] → 执行 printf

第二次调用 printf：
用户代码 → PLT[n] → GOT[n]（直接跳到 printf 真实地址）

PLT 和 GOT 的具体结构：

; PLT 条目：printf@PLT
.section .plt
printf@PLT:
    jmp   *GOT[n](%rip)        ; 第一次：跳转到下一条（因为 GOT[n] 初始指向 push 指令）
    pushq $n                   ; n 是重定位表中的索引
    jmp   PLT[0]              ; 跳转到公共桩

; PLT[0]：公共绑定桩
PLT[0]:
    pushq GOT[1]              ; link_map 结构指针
    jmp   *GOT[2]             ; _dl_runtime_resolve 地址

// GOT 表结构
GOT[0] = .dynamic 段地址           // 供动态链接器使用
GOT[1] = link_map 结构             // 当前共享对象的加载信息
GOT[2] = _dl_runtime_resolve 地址  // 符号解析函数入口
GOT[3] = printf 的实际地址         // 解析后填入
GOT[4] = malloc 的实际地址         // 解析后填入
...

_dl_runtime_resolve 的符号解析流程

1. 从 PLT 获取重定位索引 n
2. 在 .rela.plt 重定位表中查找第 n 项
3. 从 .dynsym 符号表获取符号名称字符串（.dynstr 中）
4. 在动态符号哈希表（DT_HASH 或 DT_GNU_HASH）中查找
5. 按照链接顺序在所有已加载的共享库中搜索该符号
6. 找到后，将符号的虚拟地址写入 GOT[n]
7. 跳转到符号地址执行

性能提示：DT_GNU_HASH 相比传统的 DT_HASH（ELF HASH）查找效率更高，它是基于 Bloom Filter + Bucket 的三级查找结构，时间复杂度接近 O(1)。现代 glibc 默认生成 GNU HASH。

第四部分：实战工具与调试技巧

LD_DEBUG：动态链接器的瑞士军刀

# 查看所有动态链接过程
LD_DEBUG=all ./myprogram

# 只看绑定（延迟绑定）过程
LD_DEBUG=binding ./myprogram

# 只看符号查找
LD_DEBUG=symbols ./myprogram | grep printf

# 只看文件（库搜索路径）
LD_DEBUG=files ./myprogram

# 输出到文件
LD_DEBUG_OUTPUT=/tmp/ld_debug.log LD_DEBUG=all ./myprogram

readelf & objdump：静态分析双雄

# 查看 PLT 条目
objdump -d -j .plt myprogram

# 查看 GOT 表内容
objdump -R myprogram          # 查看重定位项

# 查看动态符号表
readelf -sD myprogram         # -D 显示动态符号（.gnu.hash）

# 查看依赖库
readelf -d myprogram | grep NEEDED

# 查看是否开启 RELRO
readelf -l myprogram | grep GNU_RELRO

ltrace：追踪库函数调用

# 追踪程序的所有动态库函数调用
ltrace ./myprogram

# 只追踪特定函数
ltrace -e "printf+fprintf" ./myprogram

# 显示调用耗时
ltrace -c ./myprogram

LD_BIND_NOW：禁用延迟绑定

# 启动时立即解析所有符号（强制 Full RELRO）
LD_BIND_NOW=1 ./myprogram

这对于需要快速启动的安全关键程序（如 setuid 程序）非常有价值。

GDB 中调试 PLT/GOT

# 第一次调用前，GOT[n] 指向 PLT 的 push 指令
(gdb) x/1i 0x401030          # 查看 PLT[n]
(gdb) x/gx 0x404058          # 查看 GOT[n] 的内容（未解析时是 PLT 地址）

# 第一次调用后，GOT[n] 包含真实符号地址
(gdb) x/gx 0x404058          # 现在指向 libc 中的 printf

# 查看当前已解析的符号
(gdb) info function puts

第五部分：安全防护技术

RELRO（Relocation Read-Only）

RELRO 是一项关键的安全缓解措施，它让 GOT 表变为只读，防止攻击者通过缓冲区溢出来篡改 GOT 条目。

Partial RELRO（gcc 默认）：

• 链接时对 .got.plt 段施加 RELRO
• .got.plt 在延迟绑定完成后被标记为只读
• 但 .got 段（非 PLT GOT）仍然是可写的

Full RELRO（-Wl,-z,relro,-z,now）：

• 启动时立即解析所有符号（等价于 LD_BIND_NOW=1）
• 所有 GOT 段（.got 和 .got.plt）都被标记为只读
• 代价：启动时间稍长，但安全性显著提升

# 编译时开启 Full RELRO
gcc -Wl,-z,relro,-z,now -o myprogram main.c

# 验证
readelf -l myprogram | grep GNU_RELRO
readelf -d myprogram | grep BIND_NOW

ASLR 与 PIE

ASLR 随机化的组件：
├── 栈地址（stack）
├── 堆地址（brk/mmap）
├── 共享基址（shared libraries）
├── VDSO 页面
└── 可执行文件本身（需要 PIE）

# 检查 ASLR 设置
cat /proc/sys/kernel/randomize_va_space
# 0 = 关闭，1 = 部分（栈/库），2 = 完全（含 PIE）

# 编译 PIE 可执行文件（gcc >= 6 默认开启）
gcc -fPIE -pie -o myprogram main.c

CFI（Control Flow Integrity）

现代 LLVM/GCC 提供更高级的控制流保护：

# Clang CFI（基于前向边保护）
clang -fsanitize=cfi -fvisibility=hidden -flto -o myprogram main.c

# Intel CET（硬件级影子栈 + 间接分支追踪）
gcc -fcf-protection=full -o myprogram main.c

第六部分：性能优化实战

Prelink：预链接加速

Prelink 通过预先计算共享库的加载地址，跳过运行时重定位过程：

# 对系统所有共享库执行预链接
sudo prelink -amR

# 查看预链接对启动时间的影响
# 测试前
time firefox --headless --screenshot /tmp/test.png about:blank
# 启用 prelink 后再次测试，启动时间减少 30%-50%

注意：Prelink 会修改二进制文件本身，使得 ASLR 对预链接库无效。现代发行版（如 Fedora、Ubuntu）已逐步弃用 prelink，转而依赖 DT_GNU_HASH 快速查找 + SSD 高速 IO。

优化链接顺序

链接器按从左到右的顺序解析未定义符号，所以被依赖的库要放在后面：

# 正确：main.o 依赖 libfoo.so，libfoo.so 依赖 libbar.so
gcc -o program main.o -lfoo -lbar

# 错误：bar 在 foo 之前，可能导致未定义符号
gcc -o program main.o -lbar -lfoo   # ❌ 如果 foo 依赖 bar 的符号

对于循环依赖，使用 --start-group / --end-group：

gcc -o program main.o -Wl,--start-group -lfoo -lbar -Wl,--end-group

减少动态符号表大小

# 只导出必要的符号（默认隐藏所有）
gcc -fvisibility=hidden -o libfoo.so foo.c \
    -Wl,--version-script=libfoo.map

# libfoo.map
# {
#   global:
#     foo_init; foo_process; foo_cleanup;
#   local:
#     *;
# };

减少动态符号表不仅降低内存占用，还加速 DT_GNU_HASH 查找。

自链接二进制（-static-pie）

GCC 11+ 支持完全静态链接的 PIE 可执行文件，兼顾安全性与可移植性：

gcc -static-pie -o myprogram main.c
readelf -h myprogram | grep Type
# Type: DYN (Position-Independent Executable)

# 无需任何动态库依赖
ldd myprogram
# not a dynamic executable

第七部分：生产环境案例分析

案例一：启动慢的根因定位

问题：某微服务 Java + JNI 程序启动超过 60 秒。

# 使用 LD_DEBUG 定位瓶颈
LD_DEBUG=statistics ./java_service 2>&1 | tail -20

# 输出关键信息：
# runtime linker statistics:
#   total startup time in dynamic loader: 58234123 us
#   time needed for relocation: 52341238 us (89.8% of total time)

# 进一步发现加载了 200+ 个 .so 文件
LD_DEBUG=files ./java_service 2>&1 | grep "calling init" | wc -l
# 217

解决方案：

1. 将常用库统一基础镜像预加载到 page cache（vmtouch）
2. 对核心 .so 启用 prelink 或切换为 DT_GNU_HASH
3. 合并微小的 .so 文件为一个库
4. 改用 static-pie 链接（启动时间降至 8 秒）

案例二：ROP 攻击防护

问题：CVE 披露某服务存在栈溢出漏洞，可被用于 GOT 覆盖攻击（注入 shellcode 地址到 GOT 条目）。

缓解措施：

1. 编译时开启 Full RELRO：-Wl,-z,relro,-z,now
2. 开启 PIE + ASLR
3. 开启栈保护（Stack Canary）：-fstack-protector-strong
4. 开启 -D_FORTIFY_SOURCE=2 强化常用函数检查

验证最终二进制：

checksec --file=./myprogram
# RELRO:    Full RELRO
# Stack:    Canary found
# NX:       NX enabled
# PIE:      PIE enabled

案例三：符号冲突导致段错误

问题：程序链接了两个静态库 A 和 B，两者都定义了同名函数 utility_func()。运行时偶发段错误。

根因：ELF 动态链接器只选择第一次遇到的符号定义（先到先得），导致一个库调用了不兼容版本的函数。

定位：

LD_DEBUG=symbols ./myprogram 2>&1 | grep utility_func

# 输出显示：
# symbol=utility_func; lookup in file=./myprogram
# symbol=utility_func; lookup in file=libA.so
# binding file libA.so to libA.so: normal symbol `utility_func`

# 实际应该是 libB.so 的版本被调用!

# 解决方案：使用版本脚本隐藏其中一个符号
# libA.map { global: api_func; local: utility_func; *; };
# 或改用 RTLD_DEEPBIND 加载有冲突的库

第八部分：现代演进——多线程安全的链接

dlopen 与线程安全

dlopen() 必须保证在多线程环境下的安全性。Glibc 的实现使用 __rtld_lock_recursive 全局递归锁保护链接器状态：

dlopen()
  └── __rtld_lock_lock_recursive(GL(dl_load_lock))
       └── _dl_open()
            └── 加载目标库并递归依赖初始化
  └── __rtld_lock_unlock_recursive()

Symbol Interposition（符号拦截）

通过 LD_PRELOAD 可以在符号解析时"劫持"函数调用，实现运行时 monkey-patch：

// mymalloc.c - 拦截 malloc
#define _GNU_SOURCE
#include <dlfcn.h>
#include <stdio.h>

void *malloc(size_t size) {
    static void *(*real_malloc)(size_t) = NULL;
    if (!real_malloc) {
        real_malloc = dlsym(RTLD_NEXT, "malloc");  // 查找下一个符号定义
    }
    fprintf(stderr, "malloc(%zu) called\n", size);
    return real_malloc(size);
}

gcc -shared -fPIC -o mymalloc.so mymalloc.c -ldl
LD_PRELOAD=./mymalloc.so ./myprogram

符号拦截在生产环境中广泛用于：内存泄漏检测（jemalloc profiles）、IO 追踪、故障注入测试。

总结与速查表

加载流程速览

1. shell fork() + execve()
2. 内核验证 ELF 魔数，选择 load_elf_binary()
3. 解析 Program Header，mmap PT_LOAD 段到虚拟内存
4. BSS 零填充，建立用户栈
5. 若存在 PT_INTERP，递归加载 ld-linux.so
6. 压入辅助向量（AT_PHDR / AT_ENTRY / AT_SYSINFO_EHDR）
7. ld-linux.so 执行自举 → 加载依赖库 → 符号重定位
8. 跳转到原程序 _start → __libc_start_main → main()

重要工具链总结

工具	用途
readelf	静态查看 ELF 结构
objdump	反汇编、查看 PLT/GOT 条目
ltrace	追踪库调用
LD_DEBUG	动态链接器调试输出
checksec	安全缓解措施检查
patchelf	修改已有二进制的 RPATH/解释器
pelf	预链接加速

编译器链接选项参考

选项	效果
-Wl,-z,relro	开启 Partial RELRO
-Wl,-z,now	关闭延迟绑定
-Wl,-z,relro,-z,now	Full RELRO
-fPIE -pie	位置无关可执行文件
-fvisibility=hidden	默认隐藏符号
-static-pie	静态+PIE 二合一（GCC >= 11）
-fsanitize=cfi	控制流完整性保护

理解 ELF 加载与动态链接的底层机制，不仅能帮助你在性能调优中精准定位瓶颈，更是编写安全加固方案、排查诡异内存错误的基础功。下次当你敲下 ./program 时，脑海中浮现的不应该只是一个 Shell 提示符，而是一整套精密协作的系统工程。