.text 与 .data 所需的对齐方式

Question

我一直在玩弄ELFIO 库。尤其是One of the examples，它允许人们从头开始创建 ELF 文件——定义节、段、入口点，并为相关节提供二进制内容。

I noticed that a program created this way segfaults when the code segment alignment is chosen less than the page size (0x1000):

// Create a loadable segment
segment* text_seg = writer.segments.add();
text_seg->set_type( PT_LOAD );
text_seg->set_virtual_address( 0x08048000 );
text_seg->set_physical_address( 0x08048000 );
text_seg->set_flags( PF_X | PF_R );
text_seg->set_align( 0x1000 ); // can't change this

注意.text 部分 在同一示例中仅与 0x10 的倍数对齐：

section* text_sec = writer.sections.add( ".text" );
text_sec->set_type( SHT_PROGBITS );
text_sec->set_flags( SHF_ALLOC | SHF_EXECINSTR );
text_sec->set_addr_align( 0x10 );

但是，数据段虽然通过相同的机制单独加载，但不存在这个问题：

segment* data_seg = writer.segments.add();
data_seg->set_type( PT_LOAD );
data_seg->set_virtual_address( 0x08048020 );
data_seg->set_physical_address( 0x08048020 );
data_seg->set_flags( PF_W | PF_R );
data_seg->set_align( 0x10 ); // note here!

现在，在这种特定情况下，数据按设计适合已分配的页面。不确定这是否有任何区别，但我将其虚拟地址更改为 0x8148020，结果仍然可以正常工作。

这是readelf的输出：

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000001000 0x0000000008048000 0x0000000008048000
                 0x000000000000001d 0x000000000000001d  R E    1000
  LOAD           0x0000000000001020 0x0000000008148020 0x0000000008148020
                 0x000000000000000e 0x000000000000000e  RW     10

为什么当可执行段的对齐方式不是0x1000的倍数而数据0x10没有问题时程序执行失败？

---

更新：不知何故第二次尝试text_seg->set_align( 0x100 ); 也可以，text_seg->set_align( 0x10 ); 失败。页面大小为 0x1000，有趣的是，工作程序的 VirtAddr 在任一段中都没有遵守它：

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000100 0x08048100 0x08048100 0x0001d 0x0001d R E 0x100
  LOAD           0x000120 0x08148120 0x08148120 0x0000e 0x0000e RW  0x10

SIGSEGV 的一个：

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000080 0x08048100 0x08048100 0x0001d 0x0001d R E 0x10
  LOAD           0x0000a0 0x08148120 0x08148120 0x0000e 0x0000e RW  0x10

生成的 ELF 为 here。

Answer 1

ELF ABI 不要求 VirtAddr 或 PhysAddr 是页面对齐的。 （我相信）它只需要那个

({Virt,Phys}Addr - Offset) % PageSize == 0

这对于工作的二进制文件都是正确的，对于非工作的二进制文件是错误的。

更新：

我不明白后者是如何失败的。

我们有：VirtAddr == 0x08048100 和 Offset == 0x80（和 PageSize == 4096 == 0x1000）。

(0x08048100 - 0x80) % 0x1000 == 0x80 != 0

在 align == 0x10 时必须同意，不是吗？

不：它必须与页面大小一致（正如我之前所说的），否则内核将无法mmap 段。

Answer 2

^{（对不起，更多的是扩展评论而不是答案）}

有一些关于 ELF 可执行文件应该是什么的规范。特别阅读elf(5)，最重要的是相关的ABI规范（另请参阅this问题），例如在https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI

AFAIU，这些规范要求代码和数据段都是页面对齐的，但您需要检查这一点，特别是在 ABI 规范的第 5 章（程序加载和动态链接）中。

当前生成 ELF 可执行文件的工具（尤其是 binutils）正在努力遵守这些规范。如果您编写了一些 ELF 生成器，您还应该努力遵守这些规范（因此测试生成的 ELF 是否有效不够）。

内核正在实现execve(2)，dynamic loading 也通过ld-linux(8) 使用mmap(2) 完成。由于某些原因（可能是性能），它不会检查可执行文件是否符合所有规范。

^{（当然，内核人希望通常生成的 ELF 可执行文件能够成功execve-d）}

在某些极端情况下（例如您观察到的情况），内核并没有出现故障execve 并且对构造错误的 ELF 文件进行了处理。

但是恕我直言，对此没有任何保证。未来的内核和未来的 x86-64 处理器可能会在此类结构错误的 ELF 文件上失败。

我的感觉是你处于某个灰色地带，有点像execve 的一些“未定义行为”。如果碰巧成功了，那就是运气不好。

为什么当可执行段的对齐方式不是0x1000的倍数而数据0x10没有问题时程序执行失败？

要准确理解原因，您需要深入研究特定内核的源代码（与execve 相关）。而且我相信它可能会在未来发生变化（内核的未来版本）。

内核社区或多或少有希望过去的兼容性，但这与规范有关。在 Linux 3.10 中，某些格式错误的 ELF 可执行文件可能是 execve-d，但在 Linux 4.13 或某些未来的 Linux 5 中可能不是。

^{（我确实读过一些过去的内核已经能够execve-d 一些格式错误的 ELF 可执行文件，但我忘记了细节，可能与堆栈指针的 16 字节对齐有关）}