【问题标题】:Program header marked RWE in shared object file共享对象文件中标记为 RWE 的程序头
【发布时间】:2018-08-01 10:55:58
【问题描述】:

我在基于 Intel 的 64 位 Linux 系统上使用交叉编译器来构建我们的一些软件,以便它可以在 32 位 PowerPC 芯片上运行。交叉编译器由 Crosstools 制作。

当我对交叉编译器生成的共享对象文件(.so 文件)运行“readelf -a”时,部分输出显示如下:

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 0x00000000 0x00000000 0x9a87c 0x9a87c R E 0x10000
  LOAD           0x09a87c 0x000aa87c 0x000aa87c 0x01344 0x03230 RWE 0x10000
  DYNAMIC        0x09ba84 0x000aba84 0x000aba84 0x000d0 0x000d0 RW  0x4
  GNU_EH_FRAME   0x09a7bc 0x0009a7bc 0x0009a7bc 0x0002c 0x0002c R   0x4
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x4

问题是标头标记为 RWE。评估我们软件的潜在客户对此有疑问,并希望它只是 RW。

由相同版本的 Crosstools 生成并针对相同版本的 gcc 生成的第二个交叉编译器为 64 位 PowerPC 芯片生成代码。此交叉编译器生成的共享对象文件不生成任何 RWE 标头(第二个 LOAD 标头仅标记为 RW)。

编译和链接的 gcc 限定符在两种情况下都是相同的。

我对交叉编译器和 ELF 头文件的世界有点陌生。有没有办法让 32 位交叉编译器创建没有标头 RWE 的共享对象文件?

如果做不到这一点,有没有办法(安全地)修补已创建的 .so 文件以更改标有 RWE 的标头,使其标为 RW?

【问题讨论】:

    标签: c gcc shared-libraries elf crosstool-ng


    【解决方案1】:

    你能检查节到程序头的映射(eu-readelf -l)吗?我很确定会发生这种情况,因为您的目标配置默认没有启用前一段时间为 GNU/Linux 实现的安全 GOT 功能:

    请参阅ld and PowerPC 32-bit ELF Support 中的--bss-plt--secure-plt 以了解控制此行为的标志。如果您使用自定义程序加载器,您可能需要对其进行调整以获得安全的 PLT 支持。 glibc 动态链接器支持它。

    (恭喜你的客户非常精明。)

    编辑如果--secure-plt 不起作用,您的PowerPC 子目标要么与它不兼容,要么您构建的工具链不正确,要么有一个链接器脚本覆盖了它的效果。

    【讨论】:

    • 我们的构建系统没有 eu-readelf 命令。我在链接选项中添加了--secure-plt,在编译选项中添加了-msecure-plt。这些选项没有产生任何命令错误,但创建的 .so 文件仍然具有 RWE 标头。
    猜你喜欢
    • 2011-10-01
    • 1970-01-01
    • 2020-08-17
    • 2015-07-20
    • 1970-01-01
    • 1970-01-01
    • 2011-12-07
    • 2015-04-04
    相关资源
    最近更新 更多