在共享对象文件

时间:2018-02-21 18:31:11

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

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

当我跑步" readelf -a"对于交叉编译器生成的共享对象文件(.so文件),输出的一部分显示:

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?

1 个答案:

答案 0 :(得分:1)

您可以查看部分到程序头的映射(eu-readelf -l)吗?我很确定会发生这种情况,因为您的目标配置默认情况下不会启用为GNU / Linux实施的安全GOT功能:

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

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

编辑如果--secure-plt不起作用,您的PowerPC子目标与其不兼容,您错误地构建了工具链,或者有一个链接脚本会覆盖其效果。