Linux动态链接装载的那些事儿

h0n9xu2024-05-25 17:53

动态链接装载的步骤

在Linux上的可执行文件是一个ELF格式的文件。当我们遇到一个动态链接的可执行文件时，它是这样被执行的。

  1. 装载由LD_PRELOAD指定的动态链接库（通常为绝对路径）。
  2. 装载由/etc/ld.so.preload指定的动态链接库（通常为绝对路径）。
  3. 搜索满足该ELF文件中.dynamic节指定的NEEDED中指定的（一个或多个）动态链接库名或路径，之后装载。

对于1和2，装载动态链接库的操作是自然而然的。那么对于NEEDED，是如何找到对应的动态链接库的呢？首先如果这里的NEEDED字符串是一个相对或绝对路径，仍然不需要去搜索而只需要解析路径即可（注意，所有的相对路径均相对于当前的工作目录，而不是二进制文件相对的目录）。当动态链接库只包含了名称时，按照如下的搜索方式进行：

  1. 由ELF中的.dynamic指定的RPATH决定。注意两点：一是RPATH如今已经过时了，所以只有旧的ELF才会有这样的域；二是当.dynamic中有RUNPATH时这个域中指定的值会被忽略。
  2. 由环境变量LD_LIBRARY_PATH决定。这个环境变量生效的前提是该ELF处在非安全执行模式(non secure-execution mode)下，即ELF的AT_SECURE为0情况下------一般而言二进制可执行文件都是在这样的模式下执行的。
  3. 由ELF中的.dynamic指定的RUNPATH决定。需要注意的是，RUNPATH仅指定了直接依赖的搜索路径，搜索间接依赖的动态链接库时不会从RUNPATH中搜索（RPATH可用于直接或间接依赖的动态链接库搜索）。
  4. 由/etc/ld.so.cache指定。这个文件在我的系统上指定了一系列的动态链接库的绝对路径。需要注意的是，这个文件仅在ELF文件中NODEFLIB标志位不存在时才能生效------一般的ELF均不包含这个标志位。
  5. 默认路径/lib，/lib64，/usr/lib，/usr/lib64等等。这也要求在ELF文件中NODEFLIB标志位不存在时才能生效。

使用readelf我们可以查看一些ELF文件中的信息。比如执行readelf -d /usr/bin/man会得到如下输出：

bash 复制代码 
Dynamic section at offset 0x1b6b0 contains 32 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libmandb-2.11.2.so]
 0x0000000000000001 (NEEDED)             Shared library: [libman-2.11.2.so]
 0x0000000000000001 (NEEDED)             Shared library: [libz.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libpipeline.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000001d (RUNPATH)            Library runpath: [/usr/lib/man-db]
 0x000000000000000c (INIT)               0x5000
 0x000000000000000d (FINI)               0x15664
 0x0000000000000019 (INIT_ARRAY)         0x1c630
 0x000000000000001b (INIT_ARRAYSZ)       8 (bytes)
 0x000000000000001a (FINI_ARRAY)         0x1c638
 0x000000000000001c (FINI_ARRAYSZ)       8 (bytes)
 0x000000006ffffef5 (GNU_HASH)           0x3b0
 0x0000000000000005 (STRTAB)             0x1928
 0x0000000000000006 (SYMTAB)             0x3f8
 0x000000000000000a (STRSZ)              2990 (bytes)
 0x000000000000000b (SYMENT)             24 (bytes)
 0x0000000000000015 (DEBUG)              0x0
 0x0000000000000003 (PLTGOT)             0x1c8f0
 0x0000000000000002 (PLTRELSZ)           4776 (bytes)
 0x0000000000000014 (PLTREL)             RELA
 0x0000000000000017 (JMPREL)             0x3c40
 0x0000000000000007 (RELA)               0x2740
 0x0000000000000008 (RELASZ)             5376 (bytes)
 0x0000000000000009 (RELAENT)            24 (bytes)
 0x000000000000001e (FLAGS)              BIND_NOW
 0x000000006ffffffb (FLAGS_1)            Flags: NOW PIE
 0x000000006ffffffe (VERNEED)            0x26a0
 0x000000006fffffff (VERNEEDNUM)         1
 0x000000006ffffff0 (VERSYM)             0x24d6
 0x000000006ffffff9 (RELACOUNT)          201
 0x0000000000000000 (NULL)               0x0

  • RUNPATH：man设置了RUNPATH这个变量： 0x000000000000001d (RUNPATH) Library runpath: [/usr/lib/man-db]。

  • NEEDED：使用ls -l /usr/lib/man-db得到

bash 复制代码 
total 232K
-rw-r--r-- 1 root root 197K Jul 24  2023 libman-2.11.2.so
-rw-r--r-- 1 root root  31K Jul 24  2023 libmandb-2.11.2.so
lrwxrwxrwx 1 root root   18 Jul 24  2023 libmandb.so -> libmandb-2.11.2.so
lrwxrwxrwx 1 root root   16 Jul 24  2023 libman.so -> libman-2.11.2.so
lrwxrwxrwx 1 root root   13 Jul 24  2023 man -> ../../bin/man*
lrwxrwxrwx 1 root root   15 Jul 24  2023 mandb -> ../../bin/mandb*

在这个目录下我们发现了readelf -d /usr/bin/man结果中NEEDED项的libman-2.11.2.so和libman-2.11.2.so（这里的NEEDED像是指直接 依赖的动态链接库不带路径的库名。）。事实也是如此，在man执行时就是根据RUNPATH和NEEDED去找这两个动态链接库的。ldd /usr/bin/man | grep /usr/lib/man-db的输出为：

ini 复制代码 
        libmandb-2.11.2.so => /usr/lib/man-db/libmandb-2.11.2.so (0x00007f3512c0e000)
        libman-2.11.2.so => /usr/lib/man-db/libman-2.11.2.so (0x00007f3512acf000)

这实际上是解析了软链接后得到的真实.so文件的路径。

ldd的输出

使用ldd可以查看某个具体的二进制可执行文件或动态链接库(.so)直接或间接依赖的别的动态链接库。比如对于/usr/bin/man，使用ldd（它是一个shell脚本）可以识别出所有的依赖的动态链接库：

bash 复制代码 
$ ldd /usr/bin/man
        linux-vdso.so.1 (0x00007ffd6a9f1000)
        libachk.so => /lib/libachk.so (0x00007fc00f000000)
        libmandb-2.11.2.so => /usr/lib/man-db/libmandb-2.11.2.so (0x00007fc00f175000)
        libman-2.11.2.so => /usr/lib/man-db/libman-2.11.2.so (0x00007fc00f144000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fc00f125000)
        libpipeline.so.1 => /lib/x86_64-linux-gnu/libpipeline.so.1 (0x00007fc00f118000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc00ec00000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fc00f111000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fc00f10c000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fc00f107000)
        libgdbm.so.6 => /lib/x86_64-linux-gnu/libgdbm.so.6 (0x00007fc00efee000)
        libseccomp.so.2 => /lib/x86_64-linux-gnu/libseccomp.so.2 (0x00007fc00efce000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fc00f2bd000)
  • 这里=>的项指的是所依赖的库。如libmandb-2.11.2.so => /usr/lib/man-db/libmandb-2.11.2.so (0x00007fc00f175000)和libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc00ec00000)都是这类形式。
  • 没有=>的项有linux-vdso.so.1和/lib64/ld-linux-x86-64.so.2。其中file -b /lib64/ld-linux-x86-64.so.2的结果为/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2，但linux-vdso.so.1并不是一个绝对路径。

/lib64/ld-linux-x86-64.so.2（ld.so）

这对应着ld.so(一般位置为/usr/bin/ld.so)，它是包含动态链接库的ELF格式的二进制可执行文件的解释器 /链接库装载器 ，在ELF述语里它被称为interpreter（解释器）。在我的机器上ld.so是一个软链接，其指向了/lib64/ld-linux-x86-64.so.2；它最终指向了/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2这样一个ELF文件。

bash 复制代码 
$ which ld.so
/usr/bin/ld.so
$ file -b /usr/bin/ld.so
symbolic link to /lib64/ld-linux-x86-64.so.2
$ file -b /lib64/ld-linux-x86-64.so.2
symbolic link to /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
# 后文我们会了解到，这个文件事实上不是一个动态链接库，而是一个二进制可执行文件！
$ file -b /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=2a8cae7d0d0330d889df3265f8908abb8f19255f, stripped

一般而言，ELF可执行文件中设置了interpreter。这可以使用readelf -l /usr/bin/man来验证。

bash 复制代码 
...
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
...

当我们执行一个依赖动态链接库的二进制可执行文件时，事实上是使用了该可执行文件指定的interpreter去调用 /解释 了该可执行文件，先解决动态链接库的问题，然后执行可执行文件的逻辑。比如在执行/usr/bin/man man时，等价于执行了/usr/bin/ld.so /usr/bin/man man（或者说是/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 /usr/bin/man man）。当然我们可以强制指定ld.so。比如下面的命令同样可以得到类似于man man的结果。

bash 复制代码 
$ cp /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 /tmp/ld.so
$ /tmp/ld.so /usr/bin/man man

此外注意几点：

  • 这里的ld.so和我们平时所说的ld命令不是一个命令 。ld是链接器 ，在构建二进制 时用到；一般默认为ld.bfd(man ld.bfd)。ld.so在运行时用到。
bash 复制代码 
$ echo 'int main() { return 0; }' > /tmp/main.c
$ clang /tmp/main.c -v -o /tmp/main.out
...
 "/usr/bin/ld" -z relro --hash-style=gnu --eh-frame-hdr -m elf_x86_64 -pie -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o /tmp/main.out /lib/x86_64-linux-gnu/Scrt1.o /lib/x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_6
4-linux-gnu/13/crtbeginS.o -L/usr/lib/gcc/x86_64-linux-gnu/13 -L/usr/lib/gcc/x86_64-linux-gnu/13/../../../../lib64 -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib64 -L/lib -L/
usr/lib /tmp/main-7ac502.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-linux-gnu/13/crtendS.o /lib/x86_64-linux-gnu/crtn.o

/usr/bin/ld就是在链接时 用到的；同时我们也能看到-dynamic-linker /lib64/ld-linux-x86-64.so.2在这里指定了运行时 的解释器。对于gcc，使用gcc /tmp/main.c -v -o /tmp/main.out最后会调用/usr/libexec/gcc/x86_64-linux-gnu/13/collect2，可认为它自身也使用了ld。

  • interpreter仅针对二进制可执行文件有意义，对于动态链接库没有意义。readelf -l /path/to/bin或file -b /path/to/bin都可以查看可执行二进制的interpreter，但对于动态链接库是没有这个信息的。
bash 复制代码 
$ file -b /usr/bin/man
ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=93e22c77b20c329ec51dad530c40fd0d64fc696f, for GNU/Linux 3.2.0, stripped
  • interpreter一般设置为绝对路径($ORIGIN只能被interpreter本身所解析，所以不能用于设置interpreter相对二进制文件的位置)；如果设置为相对位置，则相对的是当前工作目录的位置而不是二进制文件的位置。
bash 复制代码 
echo 'int main() { return 0; }' > main.c
gcc -Wl,--dynamic-linker=./lib/ld-linux-x86-64.so.2 -o main main.c

mkdir bin
mkdir lib
cp /lib64/ld-linux-x86-64.so.2 lib/
cp main bin/

bin/main          # 正常运行
cd bin; ./main    # ENOENT错误("No such file or directory")

  • ldd事实上是ld.so的一个wrapper，其核心调用方式为LD_TRACE_LOADED_OBJECTS=1 ld.so /usr/bin/man（使用ld.so --list /usr/bin/man也可达到类似效果）。ldd给出的信息是所有依赖的动态链接库 ，包括直接 依赖的动态链接库和间接依赖的动态链接库(如a.so依赖b.so，则b.so也会被列出来)。

  • ld.so自身必然是一个静态链接的文件：毕竟它来解决所有的动态链接的任务嘛。

bash 复制代码 
$ ldd $(which ld.so)
        statically linked
# file的结果显示dynamically linked，事实上是错误的
$ file -bL $(which ld.so)
ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=2a8cae7d0d0330d889df3265f8908abb8f19255f, stripped

linux-vdso.so.1

通过find /lib -name '*vdso*.so*'命令，我们得到：

bash 复制代码 
/usr/lib/modules/6.2.0-32-generic/vdso/vdso32.so
/usr/lib/modules/6.2.0-32-generic/vdso/vdso64.so
/usr/lib/modules/6.5.0-28-generic/vdso/vdso32.so
/usr/lib/modules/6.5.0-28-generic/vdso/vdso64.so
/usr/lib/modules/5.4.0-94-generic/vdso/vdso32.so
/usr/lib/modules/5.4.0-94-generic/vdso/vdsox32.so
/usr/lib/modules/5.4.0-94-generic/vdso/vdso64.so
...

结合uname -r结果6.2.0-32-generic，可以猜测对应的.so为/usr/lib/modules/6.2.0-32-generic/vdso/vdso64.so。这里vDSO是virtual dynamic shared object的缩写，它是一种Linux内核自动映射到用户态应用地址空间的动态链接库；常Linux下的应用都会用它，一般不需要关心。具体详见man 7 vdso。

指定/修改动态链接信息

我们可以通过在链接时 指定动态链接的信息，也可以在运行前 对ELF文件进行修改，同时还可以在运行时进行指定。

链接时指定：ld

在链接时，我们可以指定链接信息，这样使得在生成 二进制ELF文件时的链接信息就符合用户要求。比如Linux下默认的ld.bfd或gold linker ld.gold提供了设置RUNPATH、interpreter等的选项。

  • -rpath DIR：设置DIR为RUNPATH；
  • --dynamic-linker=FILE设置FILE为interpreter。

当然一般我们不会直接使用链接器，而是通过编译器驱动程序gcc或clang时，通过选项来调用链接器。在下面的三种使用方式中，前两个gcc的调用方式（clang同理）和第三个用ld的方式效果是等价的：

  • gcc -Wl,aaa,bbb,ccc
  • gcc -Wl,aaa -Wl,bbb -Wl,ccc
  • ld aaa bbb ccc

当然，当我们使用make/cmake时，我们配置LDFLAGS就可以了，而不需要直接指定gcc/clang的选项。如LDFLAGS="-Wl,-rpath,/usr/lib/man-db"就是在链接时指定了RUNPATH为/usr/lib/man-db。

运行前修改：patchelf

patchelf是一个可以打印ELF文件信息并可以直接对ELF文件进行修改的工具，相比chrpath更为强大。

它可以打印一些内容而不做任何修改。

bash 复制代码 
$ patchelf --print-interpreter /usr/bin/man
/lib64/ld-linux-x86-64.so.2
$ patchelf --print-rpath /usr/bin/man
/usr/lib/man-db
$ patchelf --print-soname /usr/lib/x86_64-linux-gnu/libz3.so
libz3.so.4

当然，它最强大的功能是对ELF文件做修改。这在我们遇到一台机器上构建好的二进制可执行文件移植到另一台机器上执行时，尤为有效！ 事实上，patchelf是NixOS下的一个重要开源项目。

bash 复制代码 
$ 在/tmp/elf-test目录下实验
$ mkdir /tmp/elf-test
$ cp /usr/bin/man /tmp/elf-test
$ cd /tmp/elf-test && mkdir man-db
$ ldd ./man
        linux-vdso.so.1 (0x00007ffc1266e000)
        libachk.so => /lib/libachk.so (0x00007f5803700000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f58038df000)
        libmandb-2.11.2.so => /usr/lib/man-db/libmandb-2.11.2.so (0x00007f58038d7000)
        libman-2.11.2.so => /usr/lib/man-db/libman-2.11.2.so (0x00007f58038a6000)
        libpipeline.so.1 => /lib/x86_64-linux-gnu/libpipeline.so.1 (0x00007f5803899000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5803400000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f5803892000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f580388d000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f5803888000)
        libgdbm.so.6 => /lib/x86_64-linux-gnu/libgdbm.so.6 (0x00007f5803876000)
        libseccomp.so.2 => /lib/x86_64-linux-gnu/libseccomp.so.2 (0x00007f5803856000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f5803a45000)
# 把interpreter拷贝过来
$ cp /lib64/ld-linux-x86-64.so.2 /tmp/elf-test/ld.so
# 把其他非vdso的库拷贝过来
$ 把/usr/lib/man-db目录下的文件拷贝到 /tmp/elf-test/man-db下
$ cp /usr/lib/man-db/libmandb-2.11.2.so /usr/lib/man-db/libman-2.11.2.so /tmp/elf-test/man-db
$ 把其他库拷贝到 /tmp/elf-test下
$ cp /lib/libachk.so /lib/x86_64-linux-gnu/libz.so.1 /lib/x86_64-linux-gnu/libpipeline.so.1 /lib/x86_64-linux-gnu/libc.so.6 /lib/x86_64-linux-gnu/libdl.so.2 /lib/x86_64-linux-gnu/libpthread.so.0 /lib/x86_64-linux-gnu/librt.so.1 /lib/x86_64-linux-gnu/libgdbm.so.6 /lib/x86_64-linux-gnu/libseccomp.so.2 .
# 设置interpter为/tmp/elf-test/ld.so
$ patchelf --set-interpreter $PWD/ld.so man
# 设置 RUNPATH
$ patchelf --set-rpath '$ORIGIN'/.:'$ORIGIN'/man-db
$ readelf -d ./man | grep RUNPATH
 0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN/.:$ORIGIN/man-db]
$ ldd ./man
        linux-vdso.so.1 (0x00007ffe351fc000)
        libachk.so => /tmp/elf-test/././libachk.so (0x00007f0585d00000)
        libz.so.1 => /tmp/elf-test/././libz.so.1 (0x00007f0585e55000)
        libmandb-2.11.2.so => /tmp/elf-test/./man-db/libmandb-2.11.2.so (0x00007f0585e4d000)
        libman-2.11.2.so => /tmp/elf-test/./man-db/libman-2.11.2.so (0x00007f0585e1c000)
        libpipeline.so.1 => /tmp/elf-test/././libpipeline.so.1 (0x00007f0585e0f000)
        libc.so.6 => /tmp/elf-test/././libc.so.6 (0x00007f0585a00000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f0585e08000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f0585cdc000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f0585cd7000)
        libgdbm.so.6 => /lib/x86_64-linux-gnu/libgdbm.so.6 (0x00007f0585cc5000)
        libseccomp.so.2 => /lib/x86_64-linux-gnu/libseccomp.so.2 (0x00007f0585ca5000)
        /tmp/elf-test/ld.so => /lib64/ld-linux-x86-64.so.2 (0x00007f0585f9e000)
$ man man # 可以正常运行

运行时指定：ld.so

如前文所述，对于一般的二进制文件，执行/path/to/bin $@等价于于该二进制文件中指定的interpreter来显式执行/path/to/interpreter /path/to/bin $@，而这里的/path/to/interpreter即是ld.so；显式执行时，不需要再去看二进制文件中的interpreter。这样，我们可以手动指定特定的interpreter去执行对应的二进制文件。

此外，ld.so还可以指定一些选项，来约束运行时的参数。

  • 使用ld.so --library-path /dir/to/so /path/to/bin中的--library-path可以覆写LD_LIBRARY_PATH。
  • 使用ld.so --inhibit-cache /path/to/bin可以禁用/etc/ld.so.cache。
  • 使用ld.so --preload LIST /path/to/bin相当于覆写/etc/ld.so.preload。
  • 使用ld.so --inhibit-rpath LIST /path/to/bin可以禁用/path/to/bin中RPATH或RUNPATH指定的动态链接库。

这事实上可以在链接时或链接后对二进制ELF文件不做任何修改，而在执行时按照用户指定的方式去执行对应的二进制文件。

其他参考链接

相关推荐
哎呦没2 小时前
Spring Boot OA：企业办公自动化的高效路径
java·spring boot·后端
真心喜欢你吖2 小时前
Spring Boot与MyBatis-Plus的高效集成
java·spring boot·后端·spring·mybatis
2401_857636392 小时前
实验室管理技术革新：Spring Boot系统
数据库·spring boot·后端
2401_857600952 小时前
实验室管理流程优化：Spring Boot技术实践
spring boot·后端·mfc
2402_857589362 小时前
企业办公自动化：Spring Boot OA管理系统开发与实践
java·spring boot·后端
恬淡虚无真气从之3 小时前
go interface(接口)使用
开发语言·后端·golang
程序猿毕设源码分享网3 小时前
基于springboot停车场管理系统源码和论文
数据库·spring boot·后端
程序员学姐3 小时前
基于SpringBoot+Vue的高校社团管理系统
java·开发语言·vue.js·spring boot·后端·mysql·spring
.生产的驴3 小时前
Docker Seata分布式事务保护搭建 DB数据源版搭建 结合Nacos服务注册
数据库·分布式·后端·spring cloud·docker·容器·负载均衡
2401_857439694 小时前
企业OA管理系统：Spring Boot技术应用与优化
java·spring boot·后端
热门推荐
01抖音的互联网架构02PyTorch机器学习实现液态神经网络03【HarmonyOS】HUAWEI DevEco Studio 下载地址汇总04国内外大模型汇总：Open AI大模型、Google大模型、Microsoft大模型、文心一言大模型、通义千问大模型、字节豆包大模型、智普清言大模型05Coze扣子平台完整体验和实践（附国内和国际版对比）06(欧拉)openEuler系统添加网卡文件配置流程、(欧拉)openEuler系统手动配置ipv6地址流程、(欧拉)openEuler系统网络管理说明07单片机与数电模电：探索电子世界的核心领域08玄机平台应急响应—webshell查杀09RAG 实践- Ollama+RagFlow 部署本地知识库10非小米电脑下载小米电脑管家