ld 解释由黄金链接的可执行文件是否安全？答案

【问题标题】：Is it safe for ld to interpret executables linked by gold?ld 解释由黄金链接的可执行文件是否安全？
【发布时间】：2020-10-27 18:26:36
【问题描述】：

取一个简单的hello world程序，编译如下：

> g++ --version
g++ 6.3.0
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

> g++ -fuse-ld=gold test.cpp -o test

检查生成的二进制文件：

> readelf -l ./test

Elf file type is EXEC (Executable file)
Entry point 0x400750
There are 9 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  PHDR           0x0000000000000040 0x0000000000400040 0x0000000000400040
                 0x00000000000001f8 0x00000000000001f8  R      8
  INTERP         0x0000000000000238 0x0000000000400238 0x0000000000400238
                 0x000000000000001c 0x000000000000001c  R      1
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
  LOAD           0x0000000000000000 0x0000000000400000 0x0000000000400000
                 0x0000000000000ac8 0x0000000000000ac8  R E    1000
  LOAD           0x0000000000000dc0 0x0000000000401dc0 0x0000000000401dc0
                 0x0000000000000288 0x00000000000003d0  RW     1000
  DYNAMIC        0x0000000000000de0 0x0000000000401de0 0x0000000000401de0
                 0x0000000000000200 0x0000000000000200  RW     8
  NOTE           0x0000000000000254 0x0000000000400254 0x0000000000400254
                 0x0000000000000044 0x0000000000000044  R      4
  GNU_EH_FRAME   0x0000000000000a8c 0x0000000000400a8c 0x0000000000400a8c
                 0x000000000000003c 0x000000000000003c  R      4
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     0
  GNU_RELRO      0x0000000000000dc0 0x0000000000401dc0 0x0000000000401dc0
                 0x0000000000000240 0x0000000000000240  RW     8

 Section to Segment mapping:
  Segment Sections...
   00     
   01     .interp 
   02     .interp .note.ABI-tag .note.gnu.build-id .dynsym .dynstr .gnu.hash .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata .eh_frame .eh_frame_hdr 
   03     .jcr .fini_array .init_array .dynamic .got .got.plt .data .bss 
   04     .dynamic 
   05     .note.ABI-tag .note.gnu.build-id 
   06     .eh_frame_hdr 
   07     
   08     .jcr .fini_array .init_array .dynamic .got

请注意，使用的解释器是ld。虽然该程序恰好可以运行，但我无法找到任何有关这是否安全的信息。据我所知，gold 以一种微妙不同且不兼容的方式解释 ELF 规范，需要不同的解释器。

我已尽我所能对此进行研究，但找不到任何可以回答我问题的东西。我发现的最接近的是gold 很难链接 Linux 内核（或者很困难，因为时间已经过去并且它可能已经修复）。

【问题讨论】：

查看/usr/bin/gold的内容，可以看到/lib64/ld-linux-x86-64.so.2这个字符串存放在gold可执行文件里面。这意味着gold 链接器本身“决定”使用该运行时解释器。出于这个原因，我怀疑存在不兼容性。

标签： linux g++ ld elf gold-linker

【解决方案1】：

你掉进了命名陷阱——gold 是一个链接编辑器，而ld.so 是一个动态加载器。尽管在不同的时间，它们被称为链接器（后者通常也被称为运行时链接器。）

它们的范围和用法非常不同，第一个生成您最终将运行的最终可执行文件，而后者获取生成的文件，找到它的依赖关系，并解析（链接）它们之间的未定义符号。

确实，链接编辑器gold 和ld（准确地说是bfd-ld）由binutils（或替代工具链包，例如clang 等）提供，而ld.so 是由 C 库包提供，在 Linux 发行版上通常是 glibc，但也可以是 uclibc 或 musl。

将此与 Martin Rosenau 的评论结合起来......

查看/usr/bin/gold 的内容，可以看到字符串/lib64/ld-linux-x86-64.so.2 存储在gold 可执行文件中。这意味着黄金链接器本身“决定”使用该运行时解释器。出于这个原因，我怀疑存在不兼容性。

...ld.so 应该与gold 链接器兼容。

【讨论】：

man ld 告诉我ld - The GNU linker ld combines a number of object and archive files, relocates their data and ties up symbol references. Usually the last step in compiling a program is to run ld。上面明明说ld是用来编译程序的
是的。 ld 与 ld.so 不同。我同意这非常令人困惑，这就是为什么过去 10 年在我的博客上（我经常写关于链接和 elf 文件的文章）我拒绝使用“链接器”这个词，而更喜欢使用“链接编辑器”和“加载器”这个词"。
这是一个很好的观点 - 谢谢。如果将此与 Martin Rosenau 对问题的评论结合起来，这将是对该问题的完整答案。