发布于 由admin

C++ 地址无关代码（PIC）：探讨 C++ 动态库在共享内存环境下的重定位机制及其对安全性的影响

引言：C++ 地址无关代码与现代系统编程的基石

在现代操作系统中，动态链接库（Dynamic Link Libraries, DLLs 在 Windows 上，Shared Objects, SOs 在 Linux/macOS 上）是构建高效、可维护和可升级软件的关键组件。它们允许多个程序共享同一份代码和数据，从而节省内存、减少磁盘占用并简化软件更新。然而，这种共享能力并非没有代价，尤其是在多个进程可能将同一个动态库加载到各自虚拟地址空间中不同位置的场景下。这就引出了一个核心概念：地址无关代码（Position-Independent Code, PIC）。

C++ 作为一种功能强大且广泛使用的系统级编程语言，其复杂性（如虚函数、RTTI、全局/静态对象的构造与析构）对PIC的实现提出了额外的挑战。理解PIC及其在共享内存环境下的重定位机制，不仅是深入理解C++运行时行为的必经之路，更是掌握现代系统安全防护措施（如地址空间布局随机化 ASLR）的基础。

本次讲座将深入探讨C++动态库中PIC的原理、实现机制、编译器和链接器如何支持它，以及它在共享内存环境下的工作方式。我们将特别关注PIC如何影响系统安全性，例如抵御某些类型的攻击，同时也会讨论其潜在的性能开销和权衡。

动态库与地址空间的挑战

首先，让我们回顾一下动态库和虚拟内存的基本概念。

什么是动态库？
动态库是一组编译好的代码和数据，可以在程序运行时被加载和链接。与静态库（在编译时直接将代码复制到可执行文件中）不同，动态库在程序启动时或运行时才被加载到内存中。多个程序可以共享同一个动态库的物理内存副本，每个程序在自己的虚拟地址空间中拥有该库的映射。

虚拟内存与进程隔离
现代操作系统为每个进程提供一个独立的虚拟地址空间。这意味着进程A认为自己拥有从0到最大地址的完整内存范围，而进程B也如此。操作系统负责将这些虚拟地址映射到实际的物理内存地址。这种机制实现了进程间的隔离，一个进程的错误通常不会直接影响另一个进程。

当一个可执行程序启动时，它通常会被加载到虚拟地址空间中的某个固定位置。程序中的所有代码和数据引用都是相对于这个加载地址的。例如，如果一个函数被编译成 call 0x401234，那么它期望在 0x401234 处找到目标函数。这对于一个独立的可执行文件来说是可行的，因为操作系统总是会将其加载到预期的基地址。

为什么需要地址无关代码？
问题出现在动态库上。动态库不是独立的程序，它们被加载到应用程序的虚拟地址空间中。由于应用程序本身、其他动态库以及操作系统的ASLR机制，动态库无法预知自己会被加载到哪个虚拟地址。

假设一个动态库被编译时，内部函数 foo 位于库起始地址的偏移 +0x100 处。如果这个库在进程A中被加载到 0x7f0000000000，那么 foo 的地址就是 0x7f0000000100。但在进程B中，由于地址冲突或ASLR，它可能被加载到 0x7f0000100000，此时 foo 的地址就变成了 0x7f0000100100。

如果动态库中的代码包含了绝对地址引用（例如 call 0x7f0000000100），那么当库被加载到不同的基地址时，这些硬编码的地址就会失效。为了解决这个问题，操作系统加载器需要在库加载时对所有这些绝对地址进行“重定位”（relocation），即根据实际加载地址调整它们。

非PIC代码的局限性：重定位风暴
对于非PIC代码，加载器必须修改库的.text（代码）段和.data（数据）段中的所有绝对地址引用。每次加载动态库时，如果其加载地址不同，这些修改就必须重新进行。这意味着：

  1. 性能开销： 重定位操作需要CPU时间和I/O。对于大型库，这可能是一个显著的启动延迟。
  2. 内存效率低下： 由于代码段被修改，多个进程无法共享同一份物理内存中的代码副本。每个进程都必须拥有自己私有的、被修改过的代码副本，这违背了动态库节省内存的初衷。

为了克服这些局限性，地址无关代码（PIC）应运而生。PIC使得动态库的代码可以被加载到虚拟地址空间的任何位置，而无需在加载时进行修改，从而允许所有进程共享同一个物理代码副本。

地址无关代码 (PIC) 的核心机制

PIC的基本思想是：所有对地址的引用（无论是数据还是代码）都不能使用绝对地址，而必须使用相对于当前指令指针（Program Counter, PC）的相对偏移量，或者通过一个间接表进行查找。这样，无论代码被加载到哪个地址，这些相对偏移量或间接表的查找逻辑都能正常工作。

在x86-64架构上，实现PIC主要依赖于以下两种机制：全局偏移表（Global Offset Table, GOT）和过程链接表（Procedure Linkage Table, PLT），以及相对重定位。

全局偏移表 (Global Offset Table – GOT)

  • 作用： 主要用于访问全局/静态变量以及获取库内或库外函数的实际地址。
  • 工作原理： GOT是一个位于数据段（通常是.got或.got.plt）的表。它包含了一系列地址槽，每个槽在程序运行时会被填充为某个数据或函数的实际内存地址。由于GOT本身位于数据段，它是可写的。
  • 如何访问全局变量：
    当C++代码需要访问一个全局变量（例如 static int global_var; 或 extern int external_var;）时，编译器不会直接生成对 global_var 内存地址的引用。取而代之的是，它会生成代码，首先计算出GOT中 global_var 对应槽的地址（通常是相对于当前PC的偏移），然后通过这个槽间接访问 global_var。
    例如，在x86-64 Linux上，访问一个全局变量 my_global_var 的汇编伪代码可能如下：

    ; 假设当前指令位于 foo 函数内
; 获取 GOT 的地址 (通常通过 RIP 相对寻址)
lea    0x200200(%rip), %rdi    ; RDI = address of GOT entry for my_global_var
                                ; 0x200200 是一个示例偏移量，具体取决于 GOT 的位置
mov    (%rdi), %eax            ; EAX = value of my_global_var

    这里的 0x200200(%rip) 是一个相对寻址的例子。%rip 寄存器在x86-64上指向当前指令的下一条指令地址。通过一个相对于 %rip 的已知偏移量，可以定位到GOT表中的特定条目。这个条目在加载时会被动态链接器填充为 my_global_var 的实际地址。

过程链接表 (Procedure Linkage Table – PLT)

  • 作用： 用于调用外部函数（即在当前动态库之外定义的函数）。

  • 工作原理： PLT是位于代码段（.text）中的一组小“跳板”或“桩”（stubs）。每个外部函数在PLT中都有一个对应的条目。当一个函数被调用时，控制流首先跳转到其在PLT中的条目。
    PLT的工作方式结合了GOT和延迟绑定的概念，以优化性能。

    1. 首次调用：

      • 当第一次调用一个外部函数（例如 printf）时，控制流跳转到 printf 在PLT中的对应条目。
      • PLT条目中的指令会做两件事：
        • 将一个“重定位索引”（relocation index）压栈。这个索引告诉动态链接器需要解析哪个函数。
        • 跳转到PLT的第一个条目（PLT[0]）。
      • PLT[0] 负责将 _dl_runtime_resolve（动态链接器的运行时解析函数）的地址压栈，并跳转到它。
      • _dl_runtime_resolve 根据栈上的重定位索引找到 printf 的实际地址，并将其写入GOT中 printf 对应的槽位。
      • 然后 _dl_runtime_resolve 将控制流转移到 printf 的实际地址，函数得以执行。

    2. 后续调用：

      • 从第二次调用 printf 开始，控制流仍然首先跳转到 printf 在PLT中的条目。
      • 但此时，GOT中 printf 对应的槽位已经被 _dl_runtime_resolve 填充为 printf 的实际地址。
      • PLT条目中的指令会直接通过GOT槽位跳转到 printf 的实际地址，而不再需要经过 _dl_runtime_resolve，从而避免了额外的开销。

    例如，调用外部函数 external_func() 的汇编伪代码可能如下：

    ; C++ 代码: external_func();
; 编译器生成的汇编代码 (PIC)
call external_func@PLT       ; 跳转到 external_func 在 PLT 中的条目

; PLT 中的 external_func 条目 (示例)
external_func@PLT:
    jmp    QWORD PTR [rip+0x200208] ; 跳转到 GOT 中 external_func 的地址 (首次调用时指向 PLT[0] 的指令，后续指向实际函数)
    ; ... 首次调用时，这里有一些指令用于压栈和跳转到 PLT[0]

    PLT 和 GOT 共同确保了对外部函数调用的地址无关性。

相对重定位 (Relative Relocations)

虽然GOT和PLT解决了大部分地址无关问题，但对于库内部的一些指针或地址计算，还有更直接和高效的方式。R_X86_64_RELATIVE 类型的重定位就是为此而生。

  • 作用： 用于初始化库内部的指针变量，这些指针指向库内部的某个位置（代码或数据）。
  • 工作原理： 当链接器发现一个需要 R_X86_64_RELATIVE 重定位的条目时，它会记录下这个指针变量在库中的偏移量。当动态链接器加载库时，它会遍历所有的 R_X86_64_RELATIVE 条目，对于每个条目，它会将库的实际加载基地址加上该条目所指向的目标在库中的偏移量，然后将结果写入指针变量所在的内存位置。
    例如，如果库内部有一个 static const char* msg = "Hello from DLL";，msg 变量本身以及字符串字面量都在库的数据段中。msg 需要指向字符串字面量的地址。这个地址是相对于库基地址的。动态链接器会计算 库基地址 + "Hello from DLL"在库中的偏移，然后将这个结果存入 msg 变量。
  • 效率优势： 这种重定位类型不需要在运行时进行间接查找（如GOT），只需要一次简单的加法运算。因此，它比GOT查找更高效，并且由于只发生在加载时，对运行时性能没有影响。

C++ 特有挑战与解决方案

C++ 的复杂性，特别是面向对象特性，给 PIC 带来了额外的考虑。

  1. 虚函数表 (vtable) 和 RTTI：
    C++ 对象的虚函数表 (vtable) 包含虚函数的指针。如果一个类及其虚函数在动态库中定义，那么 vtable 也位于该库的数据段中。vtable 中的函数指针必须是地址无关的。编译器会确保这些指针指向的是 PIC 兼容的函数地址（可能通过 GOT 或直接的相对地址）。RTTI (Run-Time Type Information) 结构也类似，它们包含类型信息对象的指针，这些指针也需要是地址无关的。

  2. 全局/静态对象的构造与析构：
    动态库可能包含全局或静态的C++对象。这些对象的构造函数需要在库加载时执行，析构函数需要在库卸载时执行。动态链接器会查找库中的特殊段（例如 .init 和 .fini 段，或者 DT_INIT/DT_FINI 标记指向的函数，以及在现代ELF中通过 .ctors/.dtors 或 .init_array/.fini_array 机制注册的函数），来调用这些对象的构造函数和析构函数。这些构造函数和析构函数本身需要是PIC代码。

  3. 异常处理：
    C++ 异常处理机制（try-catch）依赖于运行时信息来查找合适的异常处理器。这些信息通常存储在.eh_frame 或 .gcc_except_table 等段中，并包含指向代码地址的指针。这些指针也必须是地址无关的，以确保异常能够正确地在不同地址空间中传播和处理。

  4. 名称修饰 (Name Mangling) 与符号解析：
    C++ 使用名称修饰（name mangling）来区分重载函数、类成员函数等。例如，void MyClass::myMethod(int) 会被修饰成一个复杂的字符串（如 _ZN7MyClass8myMethodEi）。动态链接器在解析符号时，会使用这些修饰后的名称来匹配函数和变量。PIC本身不直接影响名称修饰，但它依赖于链接器能够正确地解析这些修饰后的符号，以便在GOT/PLT中填充正确的地址。

线程局部存储 (Thread-Local Storage – TLS) 与 PIC

线程局部存储 (TLS) 允许每个线程拥有自己独立的全局或静态变量副本。在C++中，这通常通过 thread_local 关键字或 GCC 的 __thread 扩展实现。

在PIC环境中访问 TLS 变量需要特殊的机制，因为 TLS 变量的地址也是相对于线程存储区域的某个偏移量，而线程存储区域的基地址在不同线程甚至不同进程中都可能不同。

  • TLS 访问模型： 编译器会根据目标平台和链接器选项，选择不同的 TLS 访问模型（例如 local-exec, initial-exec, global-dynamic）。对于动态库中的 thread_local 变量，通常使用 global-dynamic 模型。
  • 工作原理： 访问 thread_local 变量通常涉及一个间接查找。首先，通过一个特殊的寄存器（如x86-64上的 fs 或 gs 段寄存器）获取当前线程的 TLS 块基地址。然后，通过一个偏移量（这个偏移量可能存储在 GOT 中，或者在加载时通过重定位计算）来访问具体的 thread_local 变量。

编译器与链接器：PIC 的幕后推手

生成PIC需要编译器和链接器的紧密协作。

  • -fPIC 编译选项：
    这是最关键的编译选项。当编译器（如GCC或Clang）看到 -fPIC 标志时，它会生成地址无关的代码。这意味着：

    • 对全局变量的访问会通过 GOT。
    • 对外部函数的调用会通过 PLT。
    • 对函数内部的静态变量或字符串字面量等，会使用相对于 %rip 的相对寻址。
    • 生成的代码中不会包含任何需要加载时修改的绝对地址。

  • -shared 链接选项：
    当链接器（如 ld）看到 -shared 标志时，它会创建一个共享库（.so 文件），而不是一个普通的可执行文件。它还会进行以下操作：

    • 创建 GOT 和 PLT。
    • 收集所有需要的重定位信息（包括 R_X86_64_RELATIVE、R_X86_64_GLOB_DAT 等），并将其存储在 .rel.dyn 或 .rela.dyn 等重定位段中。
    • 确保所有代码段都是只读的（在支持的情况下）。
    • 将库标记为动态链接器可加载的格式。

代码示例：一个简单的 C++ 共享库

让我们通过一个简单的例子来演示如何编译和使用PIC。

1. my_library.h

#ifndef MY_LIBRARY_H
#define MY_LIBRARY_H

#ifdef _WIN32
    #ifdef MY_LIBRARY_EXPORTS
        #define MY_LIBRARY_API __declspec(dllexport)
    #else
        #define MY_LIBRARY_API __declspec(dllimport)
    #endif
#else
    #define MY_LIBRARY_API __attribute__((visibility("default")))
#endif

// 一个全局变量
MY_LIBRARY_API int global_counter;

// 一个类
class MY_LIBRARY_API MyClass {
public:
    MyClass();
    void incrementCounter();
    int getCounter() const;
    virtual void virtualMethod(); // 虚函数
};

// 一个全局函数
MY_LIBRARY_API void print_message();

#endif // MY_LIBRARY_H

2. my_library.cpp

#include "my_library.h"
#include <iostream>

// 初始化全局变量
MY_LIBRARY_API int global_counter = 0;

// MyClass 的实现
MyClass::MyClass() {
    std::cout << "MyClass constructor called." << std::endl;
}

void MyClass::incrementCounter() {
    global_counter++; // 访问全局变量
}

int MyClass::getCounter() const {
    return global_counter; // 访问全局变量
}

void MyClass::virtualMethod() {
    std::cout << "MyClass::virtualMethod called." << std::endl;
}

// 全局函数实现
MY_LIBRARY_API void print_message() {
    std::cout << "Message from dynamic library. Counter: " << global_counter << std::endl;
}

// 示例：一个库内部的静态变量，用于演示 PIC 内部寻址
static int internal_static_data = 100;

// 另一个函数，访问内部静态数据
void MY_LIBRARY_API access_internal_static() {
    internal_static_data++;
    std::cout << "Internal static data incremented to: " << internal_static_data << std::endl;
}

3. main.cpp

#include "my_library.h"
#include <iostream>

int main() {
    std::cout << "Program started." << std::endl;

    // 访问库中的全局变量
    global_counter = 10;
    std::cout << "Global counter set to: " << global_counter << std::endl;

    // 使用库中的类
    MyClass obj;
    obj.incrementCounter();
    obj.incrementCounter();
    std::cout << "Counter after increments: " << obj.getCounter() << std::endl;
    obj.virtualMethod();

    // 调用库中的全局函数
    print_message();

    // 调用访问内部静态数据的函数
    access_internal_static();

    std::cout << "Program finished." << std::endl;
    return 0;
}

编译和链接（Linux/macOS）

  • 编译 my_library.cpp 为对象文件 (使用 -fPIC)：

    g++ -c -fPIC -o my_library.o my_library.cpp

    -fPIC 标志告诉编译器生成地址无关代码。

  • 链接对象文件为共享库 (使用 -shared)：

    g++ -shared -o libmy_library.so my_library.o

    -shared 标志告诉链接器创建一个共享库。

  • 编译 main.cpp 为可执行文件：

    g++ -c -o main.o main.cpp

  • 链接可执行文件，并链接共享库：

    g++ -o main main.o -L. -lmy_library

    -L. 告诉链接器在当前目录查找库，-lmy_library 链接 libmy_library.so。

  • 运行程序：
    在Linux上，需要设置 LD_LIBRARY_PATH 环境变量，让运行时链接器找到 .so 文件。

    export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:.
./main

分析工具：ldd 与 readelf

  • ldd (List Dynamic Dependencies):
    用于查看可执行文件或共享库依赖的所有动态库。

    ldd main

    输出会显示 libmy_library.so 被加载到哪个虚拟地址。每次运行都可能不同，验证了ASLR的存在。

        linux-vdso.so.1 (0x00007ffc1d7f6000)
    libmy_library.so => ./libmy_library.so (0x00007fe4159f8000) # 注意这里的地址会变
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fe4157d6000)
    libm.so.6 => /usr/lib/x86_64-linux-gnu/libm.so.6 (0x00007fe4154f3000)
    libgcc_s.so.1 => /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fe4154d8000)
    libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6 (0x00007fe4152e0000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fe415a6b000)

  • readelf (Display information about ELF files):
    一个强大的工具，用于检查ELF文件的内部结构，包括符号表、重定位表、段信息等。

    • 查看重定位信息：

      readelf -r libmy_library.so

      你会看到类似 R_X86_64_GLOB_DAT (用于GOT中的全局数据/函数指针) 和 R_X86_64_JUMP_SLOT (用于PLT中的函数调用) 等类型的重定位条目。如果启用了 RELRO，还可能看到 R_X86_64_RELATIVE 用于在加载时填充内部指针。

      重定位节 '.rela.dyn' 于偏移量 0x768 包含 12 个条目:
  偏移量          信息           类型              符号值  符号名称 + 添加数
000000201000  000000000008 R_X86_64_RELATIVE   0000000000000000
000000201008  000000000008 R_X86_64_RELATIVE   0000000000000000
000000201010  000000000008 R_X86_64_RELATIVE   0000000000000000
...
000000201068  000000000006 R_X86_64_GLOB_DAT   0000000000000000 _ZTI7MyClass + 0
000000201070  000000000006 R_X86_64_GLOB_DAT   0000000000000000 _ZTV7MyClass + 0
000000202028  000000000001 R_X86_64_JUMP_SLOT  0000000000000000 _ZSt4cout + 0
000000202030  000000000001 R_X86_64_JUMP_SLOT  0000000000000000 _ZNSolsEPFRSoS_E + 0
000000202038  000000000001 R_X86_64_JUMP_SLOT  0000000000000000 _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcSt11char_traitsIcEES5_PKc + 0
...

      这里的 R_X86_64_RELATIVE 重定位用于初始化库内部的指针（例如虚函数表中的指针），它们在加载时会被加上库的基地址。R_X86_64_GLOB_DAT 用于 _ZTI7MyClass (RTTI) 和 _ZTV7MyClass (vtable)，它们的地址需要在GOT中被填充。R_X86_64_JUMP_SLOT 用于 std::cout 等外部函数的第一次调用，通过PLT和GOT进行解析。

    • 查看段信息：

      readelf -S libmy_library.so

      你会看到 .text (代码段), .data (已初始化数据段), .bss (未初始化数据段), .got.plt (GOT), .plt (PLT) 等段。

这些工具是理解动态链接和PIC机制的宝贵资源。

共享内存环境下的重定位

现在，让我们把PIC的讨论扩展到共享内存环境。当多个进程需要协作并共享数据时，共享内存是一种高效的进程间通信（IPC）机制。

共享内存 (Shared Memory) 的概念

共享内存允许不同的进程访问同一块物理内存区域。操作系统将这块物理内存映射到每个参与进程的虚拟地址空间中。一旦映射完成，进程就可以像访问自己的私有内存一样访问共享内存，避免了数据拷贝的开销。

mmap 系统调用

在类Unix系统上，mmap 是创建和管理内存映射的关键系统调用。它可以用来：

  • 将文件映射到内存中（包括可执行文件和共享库）。
  • 创建匿名共享内存区域（不与任何文件关联）。

PIC 如何确保动态库在不同进程中共享同一份物理内存

这是PIC设计最核心的目标之一。当一个动态库被加载时：

  1. 代码段共享： 动态链接器将 .text（代码）段映射到进程的虚拟地址空间。由于PIC代码是地址无关的，它不包含任何需要修改的绝对地址。因此，所有加载这个动态库的进程都可以共享同一份物理内存中的 .text 段副本。这大大节省了物理内存。
  2. 数据段私有化与共享：
    • .data（已初始化数据）和 .bss（未初始化数据）段通常是进程私有的，或者至少是可写的。如果多个进程共享同一个可写的数据段，一个进程的修改会影响所有进程。
    • 对于动态库，其 .data 和 .bss 段通常会在每个进程加载时被复制一份（写时复制，Copy-On-Write, COW），或者直接映射为私有的可写内存区域。这意味着，虽然代码是共享的，但全局变量和静态变量的实例对于每个进程是独立的。
    • GOT 位于数据段（或其一部分，.got.plt），因此每个进程都有自己的 GOT 副本。动态链接器会在每个进程中独立地填充其 GOT 副本，确保其中的地址指向该进程虚拟地址空间中正确的地址。

虚拟地址与物理地址的映射

假设动态库 libfoo.so 被进程A和进程B加载。

  • 进程A的虚拟地址空间： libfoo.so 的 .text 段可能被映射到 0x7f1000000000。
  • 进程B的虚拟地址空间： libfoo.so 的 .text 段可能被映射到 0x7f2000000000。

尽管在虚拟地址空间中，两个进程看到的 libfoo.so 的起始地址不同，但它们都指向同一块物理内存。操作系统的内存管理单元 (MMU) 负责将这些不同的虚拟地址映射到相同的物理页面。

多个进程加载同一动态库的图示（文字描述）

想象一下：

内存区域 进程 A 的虚拟地址 进程 B 的虚拟地址 物理内存映射
libfoo.so .text 0x7f1000000000 0x7f2000000000 共享的物理页面 (只读)
libfoo.so .data 0x7f1000010000 0x7f2000010000 进程 A 私有的物理页面 (可写)
进程 B 私有的物理页面 (可写)
libfoo.so .got 0x7f1000010100 0x7f2000010100 进程 A 私有的物理页面 (可写)
进程 B 私有的物理页面 (可写)
main可执行文件 0x004000000000 0x004000000000 进程 A 私有的物理页面 (可写代码)
进程 B 私有的物理页面 (可写代码)

这张图示清晰地展示了，即使 libfoo.so 的代码段在不同进程中映射到了不同的虚拟地址，它们仍然可以指向同一份物理内存。而数据段（包括GOT）则通常是每个进程独立的，以允许它们独立地修改全局状态和重定位条目。

PIC 对系统安全性的深远影响

PIC不仅解决了内存效率和加载性能问题，还在现代系统安全防护中扮演着核心角色。它使得许多安全机制得以有效实施，从而增加了攻击者利用漏洞的难度。

地址空间布局随机化 (ASLR)

  • ASLR 的目标： ASLR是一种安全技术，旨在通过随机化可执行文件在内存中的加载地址、堆、栈和动态库的地址来防止内存攻击。其核心思想是，如果攻击者无法预测特定代码或数据的内存地址，就难以构造精确的攻击载荷（如ROP链、shellcode注入）。
  • PIC 作为 ASLR 的基石： ASLR要有效，其所随机化的模块必须是地址无关的。如果一个动态库不是PIC，那么每次加载它都需要进行重定位。如果其基地址被随机化，那么这些重定位操作将每次都不同，并且会修改代码段。这使得ASLR无法真正发挥作用，因为攻击者可以通过信息泄露（例如，读取 /proc/self/maps）或暴力猜测来确定加载地址，然后利用已经被修改的代码段中的固定偏移量。
    有了PIC，动态库的代码段是只读且地址无关的，因此可以被随机加载到任何地址而无需修改。这使得ASLR能够有效地随机化动态库的基地址，从而显著增加了攻击者预测目标地址的难度。

只读重定位表 (Read-Only Relocation – RELRO)

  • 防止 GOT 覆写攻击： GOT 是一个可写的表，在程序运行时被动态链接器填充为外部函数的实际地址。如果攻击者能够控制GOT，他们就可以将某个函数的GOT条目修改为指向恶意代码的地址。当程序下次调用该函数时，就会跳转到攻击者的代码，从而实现任意代码执行。
  • 完全 RELRO 与部分 RELRO：
    • 部分 RELRO (-z relro)： 链接器将 .got 和 .got.plt 合并为一个 .got.plt 段，并在加载时将其标记为只读。但是，PLT 的延迟绑定机制仍然需要 .got.plt 的一部分在运行时被修改。因此，这部分在初始化完成后仍然是可写的。
    • 完全 RELRO (-z now)： 结合 -z relro 和 -z now（或 DT_BIND_NOW）。-z now 告诉动态链接器在程序启动时立即解析所有符号，而不是延迟解析。这意味着所有GOT条目在程序启动前就已经被填充，并且整个 .got.plt 段可以被标记为完全只读。
  • ld 链接选项： 
    g++ -shared -o libmy_library.so my_library.o -Wl,-z,relro,-z,now

    这个选项使得 libmy_library.so 具有完全 RELRO 保护。这使得GOT覆写攻击几乎不可能实现，因为GOT在程序启动后就变成了只读。

写-异或-执行 (W^X)

  • 内存页的权限分离： W^X (Write XOR Execute) 原则要求内存页面要么是可写但不可执行，要么是可执行但不可写，但不能同时可写和可执行。这是数据执行保护 (DEP) 的核心思想。
  • PIC 如何支持 W^X：
    • PIC 代码段（.text）是只读且可执行的。由于它不包含需要运行时修改的绝对地址，因此可以安全地标记为不可写。
    • PIC 数据段（.data、.bss、.got）是可写但不可执行的。
      这种清晰的分离使得W^X原则可以被严格实施。
  • 防止代码注入： 如果一个内存区域同时可写又可执行，攻击者可以将恶意代码写入该区域，然后跳转到那里执行。W^X 原则通过确保没有这样的区域来阻止这种攻击，从而显著提高了系统的安全性。

数据执行保护 (DEP/NX)

  • 与 W^X 的关系： DEP (Data Execution Prevention) 或 NX (No-Execute) 位是硬件层面的安全特性，它允许操作系统将内存页标记为不可执行。这直接强制执行了 W^X 原则。
  • 作用： 防止攻击者将数据（例如注入的 shellcode）放置在通常不可执行的内存区域（如堆栈、数据段）并尝试执行它们。PIC 代码和数据分离的特性使其与DEP/NX高度兼容。

潜在的安全隐患与最佳实践

尽管PIC增强了安全性，但不当使用或配置仍可能带来风险：

  • 非 PIC 代码在共享库中的风险： 如果一个共享库不是用 -fPIC 编译的，那么它将包含需要加载时重定位的绝对地址。这会破坏ASLR的有效性，因为攻击者可以通过泄露基地址来计算出所有代码和数据的精确位置。此外，为了重定位，库的代码段必须是可写的，这违反了W^X原则，为攻击者提供了代码注入的机会。
  • 不正确的链接选项： 未使用 -z now 的部分 RELRO 仍然存在 GOT 覆写风险。虽然攻击者需要更复杂的手段（例如先泄露地址，再覆写），但并非不可能。
  • 延迟绑定 (Lazy Binding) 的安全考量： 虽然延迟绑定可以提高程序启动速度，但它也意味着在第一次调用函数之前，GOT中对应的条目是可写的。攻击者可能利用这个短暂的窗口来修改GOT。完全 RELRO 通过强制立即绑定来消除此风险。

最佳实践：
始终使用 -fPIC 编译共享库。
始终使用 -shared -Wl,-z,relro,-z,now 链接共享库和可执行文件，以确保完全 RELRO 和强大的 ASLR 兼容性。

性能考量与权衡

PIC 并非没有代价。其间接寻址的特性会引入一定的性能开销。

  • GOT/PLT 查找的开销：
    • 访问全局变量或外部函数时，需要额外的内存访问（GOT查找）或额外的跳转指令（PLT）。这些间接性会增加少量指令周期。
    • 对于外部函数，首次调用时的动态解析过程会引入显著的延迟，但后续调用会快得多。
  • 缓存局部性：
    间接寻址可能会导致CPU缓存命中率略微下降，因为数据和代码不再是直接相邻的。GOT通常位于数据段，而代码在代码段，这可能会导致更多的缓存行失效。
  • PIC 代码的尺寸略有增加：
    为了实现地址无关性，编译器可能需要生成更多的指令。例如，使用 lea 指令结合 %rip 相对寻址来计算地址，而不是直接使用绝对地址。这会导致可执行文件和库的二进制大小略微增加。
  • 现代 CPU 架构的优化：
    现代CPU在处理分支预测和缓存方面非常高效。GOT/PLT的间接查找通常可以被CPU很好地预测和缓存，因此实际的性能影响在大多数情况下并不显著，尤其是在IO密集型或CPU密集型但代码分支不频繁的应用中。
  • 何时选择非 PIC (静态链接或特定场景)：
    • 对于完全静态链接的可执行文件（即不依赖任何动态库），通常不需要PIC，因为整个程序在加载时有一个固定的基地址。这种情况下，使用非PIC代码可以获得微小的性能提升和更小的二进制大小。
    • 在一些极致性能敏感的嵌入式系统或微控制器上，如果内存资源极其有限且不需要动态加载，可能会选择非PIC代码。
    • 在C++中，dlopen 加载的模块必须是PIC。

在绝大多数现代应用中，PIC所带来的内存共享、启动速度和安全性优势远远超过了其微小的性能开销。因此，将共享库编译为PIC是默认且推荐的做法。

结论

C++ 地址无关代码（PIC）是现代操作系统和动态链接机制的基石。它使得动态库能够被加载到进程虚拟地址空间的任意位置，同时允许多个进程共享同一份物理代码副本，从而显著提高了内存效率和系统灵活性。通过全局偏移表（GOT）、过程链接表（PLT）以及相对重定位等机制，PIC优雅地解决了动态加载和重定位的挑战。

更重要的是，PIC是现代系统安全防护措施（如ASLR、RELRO和W^X）得以有效实施的先决条件。它通过消除可重定位的代码段和限制可写内存区域的执行权限，极大地增加了攻击者利用内存漏洞的难度。尽管存在轻微的性能开销，但鉴于其在资源优化和系统安全方面的巨大贡献，PIC在绝大多数现代C++应用中都是不可或缺的。深入理解PIC及其背后的机制，是每一位C++系统级开发者迈向高级编程和安全加固的必经之路。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注