加载的 ELF 段的重叠映射

Question

我想详细了解动态加载器如何为 ELF 段创建映射。

考虑一个与 GNU ld 链接的小型共享库。程序头是：

类型 偏移 VirtAddr PhysAddr FileSiz MemSiz Flg Align 加载 0x000000 0x0000000000000000 0x0000000000000000 0x00095c 0x00095c R E 0x200000 加载 0x000df8 0x0000000000200df8 0x0000000000200df8 0x000250 0x000258 读写 0x200000 动态 0x000e08 0x0000000000200e08 0x0000000000200e08 0x0001d0 0x0001d0 RW 0x8 GNU_EH_FRAME 0x000890 0x0000000000000890 0x0000000000000890 0x00002c 0x00002c R 0x4 GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 读写 0x10 GNU_RELRO 0x000df8 0x0000000000200df8 0x0000000000200df8 0x000208 0x000208 R 0x1

这个共享对象可以打印它加载的进程的映射（/proc/self/maps），sn-p：

7fd1f057b000-7fd1f057c000 r-xp 00000000 fe:00 12090538 /path/libmy.so 7fd1f057c000-7fd1f077b000 ---p 00001000 fe:00 12090538 /path/libmy.so 7fd1f077b000-7fd1f077c000 r--p 00000000 fe:00 12090538 /path/libmy.so 7fd1f077c000-7fd1f077d000 rw-p 00001000 fe:00 12090538 /path/libmy.so

如果我打印一个可变全局变量的地址，打印的地址在第四个映射中。

1. 这四种映射各自的用途是什么？
2. 为什么动态加载器会创建一个没有权限的“填充”映射？

---

解构映射：

基地址 == 7fd1f057b000 映射1：虚拟偏移0x000000，大小0x001000，R-X，从文件偏移0x0000 映射2：虚拟偏移0x001000，大小0x1ff000，---，从文件偏移0x1000 映射3：虚拟偏移0x200000，大小0x001000，R--，从文件偏移0x0000 映射4：虚拟偏移0x201000，大小0x001000，RW-，从文件偏移0x1000

---

我目前的理解：

广告 1。

1. 第一个映射是“文本”段（第一个程序头）。
2. 第二个映射看起来像一种填充形式（没有权限和大小，因此下一个段的虚拟偏移量为 0x200000）。
3. ???
4. “数据”段。除了我会说它应该从文件偏移量 0 开始并且大小为 0x2000。该段从文件中的 0xdf8 开始，仍然在第一页上。还有，“文本”段的文件大小怎么会大于“数据”段的偏移量？

Ad 2. 链接器不能只请求在确切的虚拟地址 7fd1f077b000 上进行映射，从而创建一个漏洞吗？为什么要打扰这个映射？

---

$ readelf -d libmy.so

Dynamic section at offset 0xe08 contains 25 entries:
Tag        Type                         Name/Value
0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
0x000000000000000c (INIT)               0x5a8
0x000000000000000d (FINI)               0x848
0x0000000000000019 (INIT_ARRAY)         0x200df8
0x000000000000001b (INIT_ARRAYSZ)       8 (bytes)
0x000000000000001a (FINI_ARRAY)         0x200e00
0x000000000000001c (FINI_ARRAYSZ)       8 (bytes)
0x0000000000000004 (HASH)               0x190
0x000000006ffffef5 (GNU_HASH)           0x1e0
0x0000000000000005 (STRTAB)             0x380
0x0000000000000006 (SYMTAB)             0x218
0x000000000000000a (STRSZ)              172 (bytes)
0x000000000000000b (SYMENT)             24 (bytes)
0x0000000000000003 (PLTGOT)             0x201000
0x0000000000000002 (PLTRELSZ)           120 (bytes)
0x0000000000000014 (PLTREL)             RELA
0x0000000000000017 (JMPREL)             0x530
0x0000000000000007 (RELA)               0x470
0x0000000000000008 (RELASZ)             192 (bytes)
0x0000000000000009 (RELAENT)            24 (bytes)
0x000000006ffffffe (VERNEED)            0x450
0x000000006fffffff (VERNEEDNUM)         1
0x000000006ffffff0 (VERSYM)             0x42c
0x000000006ffffff9 (RELACOUNT)          3
0x0000000000000000 (NULL)               0x0

---

$ readelf -Wl libmy.so

Elf file type is DYN (Shared object file)
Entry point 0x630
There are 6 program headers, starting at offset 64

Program Headers:
Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
LOAD           0x000000 0x0000000000000000 0x0000000000000000 0x00095c 0x00095c R E 0x200000
LOAD           0x000df8 0x0000000000200df8 0x0000000000200df8 0x000250 0x000258 RW  0x200000
DYNAMIC        0x000e08 0x0000000000200e08 0x0000000000200e08 0x0001d0 0x0001d0 RW  0x8
GNU_EH_FRAME   0x000890 0x0000000000000890 0x0000000000000890 0x00002c 0x00002c R   0x4
GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW  0x10
GNU_RELRO      0x000df8 0x0000000000200df8 0x0000000000200df8 0x000208 0x000208 R   0x1

 Section to Segment mapping:
  Segment Sections...
   00     .hash .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .plt.got .text .fini .rodata .eh_frame_hdr .eh_frame
   01     .init_array .fini_array .dynamic .got .got.plt .data .bss
   02     .dynamic
   03     .eh_frame_hdr
   04
   05     .init_array .fini_array .dynamic .got

Answer 1

这四个映射各自的目的是什么？
为什么动态加载器会创建一个没有权限的“填充”映射？

为了了解最终状态，我们需要跟踪动态链接器所采取的操作。它的“指示”是什么？它需要将ET_DYN 对象加载到内存中的随机地址（由操作系统选择）。映射必须满足这些“命令”（我省略了 PhysAddr，因为它与 VirtAddr 相同）：

       Offset   VirtAddr           FileSiz  MemSiz   Flg Align
LOAD   0x000000 0x0000000000000000 0x00095c 0x00095c R E 0x200000
LOAD   0x000df8 0x0000000000200df8 0x000250 0x000258 RW  0x200000

现在，对于所有 ELF 二进制文件来说最重要的第一件事是，为了正常工作，两个 LOAD 段 必须 重新定位相同的“基本偏移量”。它不会做，例如mmap 第一个LOAD 段在0x1000000，第二个在0x2000000+0x200df8 == 0x2200df8。

出于这个原因，动态链接器（我将使用 rtld 收缩）必须将 两个 段的 mmap 作为单个 @987654331 执行@ （否则，不能保证第二个映射不会干扰已经映射到那里的其他东西）。所以它执行：

size_t len = 0x200df8 + 0x258;
void *base = mmap(0, len, PROT_READ|PROT_EXEC, MAP_PRIVATE, fd, 0);

在您的特定情况下，base == 0x7fd1f057b000，我们有一个映射，涵盖 .text 和 .data：

7fd1f057b000-7fd1f077d000 r-xp 0 libmy.so

但rtld 远未完成。它现在必须将mmap .data（第二个）LOAD 段放到正确的位置并具有所需的权限（省略错误检查）：

  mmap(base + 0x200000, 0xdf8 + 0x258, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0);

我们的映射现在如下所示：

7fd1f057b000-7fd1f077b000 r-xp 0 libmy.so
7fd1f077b000-7fd1f077d000 rw-p 0 libmy.so

接下来，我们的文件非常短（小于 4K），如果我们更喜欢简单的SIGSEGV，则将地址保留在映射的[0x7fd1f057c000, 0x7fd1f077b000) 范围内可能会产生SIGBUS 或其他令人困惑的错误。

我们可以munmap 这个区域，但是有缺点（其他一些小型库可能会落在那个几乎 2MiB 的区域中，并且会混淆 rtld 的其他部分以寻找最近的基本映射）。相反，rtld 保护该区域，禁止访问，同时保持映射完整：

mprotect(0x7fd1f057c000, 0x1ff000, PROT_NONE);

现在我们的内存映射看起来几乎就像您观察到的最终结果：

7fd1f057b000-7fd1f077b000 r-xp 0 libmy.so
7fd1f057c000-7fd1f077b000 ---p 0 libmy.so
7fd1f077b000-7fd1f077d000 rw-p 0 libmy.so

但是rtld 还需要做一件事：您的对象请求（由于拥有GNU_RELRO 段）在重定位后保护其一部分可写数据不被写入。所以rtld执行重定位，然后执行最后的mprotect：

mprotect(base + 0x200000, 0xdf8 + 0x208, PROT_READ);

这会产生最终的内存映射（与您观察到的完全匹配）：

7fd1f057b000-7fd1f077b000 r-xp 0 libmy.so
7fd1f057c000-7fd1f077b000 ---p 0 libmy.so
7fd1f077b000-7fd1f077c000 r--p 0 libmy.so
7fd1f077c000-7fd1f077d000 rw-p 0 libmy.so

我在查找有关 GNU_RELRO 的文档时遇到了一些问题。

有一个很好的讨论here。

我猜它的 VirtAddr 和 FileSize 指定了哪些部分应该是只读的？

正确，但它是 MemSize（但它应该始终匹配 FileSize）。

所以没有使用section table？

在动态链接期间从不使用节表，它可以在删除节表的完全剥离的二进制文件上工作。节表保留在二进制文件中（默认情况下）仅用于帮助调试。