ld 解释由 gold 链接的可执行文件是否安全?
Is it safe for ld to interpret executables linked by gold?
拿一个简单的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
努力 link Linux 内核(或者努力,因为时间已经过去并且它可能已经修复)。
您掉进了命名陷阱 — gold
是 link 编辑器 ,而 ld.so
是 动态加载器。尽管在不同的时间,它们被称为linkers(后者通常也被称为运行time linker.)
它们的范围和用法非常不同,第一个生成最终的可执行文件,你最终会 运行,而后者获取生成的文件,找到它的依赖项,并解析 (link s) 它们之间的未定义符号。
事实上,gold
和 ld
(准确地说,bfd-ld
),link 编辑器,是由 binutils
(或其他工具链包,如如 clang
等),而 ld.so
由 C 库包提供,通常 glibc
在 Linux 发行版上,但也可以选择 uclibc
或 musl
.
结合 Martin Rosenau 的评论...
Looking at the content of /usr/bin/gold, you can see that the string /lib64/ld-linux-x86-64.so.2 is stored inside the gold executable. This means that the gold linker itself "decides" using that runtime interpreter. For this reason I doubt that there are incompatibilities.
...ld.so
应该与 gold
linker.
兼容
拿一个简单的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
努力 link Linux 内核(或者努力,因为时间已经过去并且它可能已经修复)。
您掉进了命名陷阱 — gold
是 link 编辑器 ,而 ld.so
是 动态加载器。尽管在不同的时间,它们被称为linkers(后者通常也被称为运行time linker.)
它们的范围和用法非常不同,第一个生成最终的可执行文件,你最终会 运行,而后者获取生成的文件,找到它的依赖项,并解析 (link s) 它们之间的未定义符号。
事实上,gold
和 ld
(准确地说,bfd-ld
),link 编辑器,是由 binutils
(或其他工具链包,如如 clang
等),而 ld.so
由 C 库包提供,通常 glibc
在 Linux 发行版上,但也可以选择 uclibc
或 musl
.
结合 Martin Rosenau 的评论...
Looking at the content of /usr/bin/gold, you can see that the string /lib64/ld-linux-x86-64.so.2 is stored inside the gold executable. This means that the gold linker itself "decides" using that runtime interpreter. For this reason I doubt that there are incompatibilities.
...ld.so
应该与 gold
linker.