Linux ELF文件和VMA间的关系

最新推荐文章于 2025-04-13 10:41:54 发布

阿曼

最新推荐文章于 2025-04-13 10:41:54 发布

阅读量2.4k

点赞数 2

分类专栏： Linux内核

本文链接：https://blog.youkuaiyun.com/rockrockwu/article/details/81707909

版权

Linux内核专栏收录该内容

30 篇文章

订阅专栏

本文探讨了Linux系统中ELF格式的可执行文件如何被加载到进程虚拟内存(VMA)中，通过具体实例深入分析了ELF文件的section与segment的概念及它们与进程内存布局之间的关系。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

本来打算写一下内核do_execve的实现。但是do_execve实现需要结合image 二进制文件结构。并且网上也有很多分析do_execve的文章，很多都写得非常棒。
比如:https://blog.youkuaiyun.com/conansonic/article/details/53740670 这篇就写得非常详细了。如果光看do_execve的流程看这篇就足够了。
为了不重复造轮子，这篇就先写ELF格式和进程虚拟内存布局的关系。了解下Linux是如何加载二进制可执行文件到VM(进程虚拟内存)中的。
在介绍之前强烈推荐一本书《程序员的自我修养》！从研究生阶段到现在我看过不下三遍。而且看完PDF后又买了正版纸质。作为收藏也是支持作者。
本文涉及的编译链接的很多内容都可以从那本书上找到。当然如果你有耐心也可以直接看神书《Linker and Loader》。
为了更好的解释来龙去脉，准备了一个hello_world的小程序。代码如下：

  1 #include<stdio.h>                                                                                                                                                                                       
  2 #include<unistd.h>
  3  
  4 int main()
  5 {
  6     printf("hello world!\n");
  7  
  8     while(1) {
  9         sleep(1);
 10     }
 11  
 12     return 0;
 13 }

在分析之前先列出hello_world运行起来时在内存中的布局。通过cat /proc/进程号/maps就能看到这个布局。

binwu@binwu3-DESK2:~/work/hello_world$ ./hello_world &
[3] 25665
binwu@binwu3-DESK2:~/work/hello_world$  cat /proc/25665/maps
00400000-00401000 r-xp 00000000 00:31 33565665                           /home/binwu/work/hello_world/hello_world
00600000-00601000 r--p 00000000 00:31 33565665                           /home/binwu/work/hello_world/hello_world
00601000-00602000 rw-p 00001000 00:31 33565665                           /home/binwu/work/hello_world/hello_world
01bae000-01bcf000 rw-p 00000000 00:00 0                                  [heap]
7f2a07684000-7f2a07844000 r-xp 00000000 fd:01 41161121                   /lib/x86_64-linux-gnu/libc-2.23.so
7f2a07844000-7f2a07a44000 ---p 001c0000 fd:01 41161121                   /lib/x86_64-linux-gnu/libc-2.23.so
7f2a07a44000-7f2a07a48000 r--p 001c0000 fd:01 41161121                   /lib/x86_64-linux-gnu/libc-2.23.so
7f2a07a48000-7f2a07a4a000 rw-p 001c4000 fd:01 41161121                   /lib/x86_64-linux-gnu/libc-2.23.so
7f2a07a4a000-7f2a07a4e000 rw-p 00000000 00:00 0 
7f2a07a4e000-7f2a07a74000 r-xp 00000000 fd:01 41161093                   /lib/x86_64-linux-gnu/ld-2.23.so
7f2a07c32000-7f2a07c35000 rw-p 00000000 00:00 0 
7f2a07c73000-7f2a07c74000 r--p 00025000 fd:01 41161093                   /lib/x86_64-linux-gnu/ld-2.23.so
7f2a07c74000-7f2a07c75000 rw-p 00026000 fd:01 41161093                   /lib/x86_64-linux-gnu/ld-2.23.so
7f2a07c75000-7f2a07c76000 rw-p 00000000 00:00 0 
7ffe3388d000-7ffe338ae000 rw-p 00000000 00:00 0                          [stack]
7ffe33982000-7ffe33985000 r--p 00000000 00:00 0                          [vvar]
7ffe33985000-7ffe33987000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

可以发现，这里进程中有多个VMA。有hello_world本身的VMA，也有链接了glibc库之后，给库分配的VMA。这里只看hello_world本身的VMA。我们带着一些问题来看这个maps的信息，这样回更有针对性一些。比如：

Linux根据什么信息来将hello_world可执行文件分散加载到各个VMA中?
和hello_world相关的VMA正好有三个。而且读写属性分别是rx/r/rw。他们和代码段/数据段/堆栈段是一一对应的关系吗？
上一个问题看起来是否定的。因为最后那个rw属性的段不是堆栈段。因为已经有独立的栈段了，在倒数第四个。那这三个段对应的是什么呢？

接下来一一分析。

ELF格式

可执行文件是有格式的。比如windows下的exe，linux中的a.out/COFF/ELF等。它们都是有不同format的。这里编译的hello_world产生的是ELF格式的可执行文件。我们通过readelf这个工具来分析elf格式的文件信息。在分析之前简单回顾下ELF格式的定义。可以参考这份文档：http://refspecs.linuxbase.org/elf/elf.pdf

#ELF格式说明

ELF格里经常可以看到sections和segments。这虽说中文都可以翻译成”段”，但是有什么区别呢？前面的文档中就给出了答案。如下所示：
这里写图片描述
可以知道，sections对应的是链接的视角，segments对应的是执行时的视角。比如说我们的代码(read only)在链接时被放到了text代码段里，这个段说的就是section，同理还有data section/bss section等；当可执行文件需要根据不同的段被加载到进程VM中的不同区域时，这个段就是指segment了。这篇文章因为分析的是加载的过程，所以关心的段是segment。接着在用readelf工具来看下这个ELF文件。

binwu@binwu3-DESK2:~/work/hello_world$ readelf -l hello_world

Elf file type is EXEC (Executable file)
Entry point 0x400470
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 E    8
  INTERP         0x0000000000000238 0x0000000000400238 0x0000000000400238
                 0x000000000000001c 0x000000000000001c  R      1
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
  LOAD           0x0000000000000000 0x0000000000400000 0x0000000000400000
                 0x000000000000073c 0x000000000000073c  R E    200000
  LOAD           0x0000000000000e10 0x0000000000600e10 0x0000000000600e10
                 0x0000000000000230 0x0000000000000238  RW     200000
  DYNAMIC        0x0000000000000e28 0x0000000000600e28 0x0000000000600e28
                 0x00000000000001d0 0x00000000000001d0  RW     8
  NOTE           0x0000000000000254 0x0000000000400254 0x0000000000400254
                 0x0000000000000044 0x0000000000000044  R      4
  GNU_EH_FRAME   0x0000000000000614 0x0000000000400614 0x0000000000400614
                 0x0000000000000034 0x0000000000000034  R      4
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     10
  GNU_RELRO      0x0000000000000e10 0x0000000000600e10 0x0000000000600e10
                 0x00000000000001f0 0x00000000000001f0  R      1

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

从打印信息看，总共有9个segments。但是不巧的是和前面打印的maps看到的那几个段对不上。所以这几个segments分别代表什么含义呢？如下：

PT_NULL

The array element is unused and the other members’ values are undefined. This lets the program header have ignored entries.

PT_LOAD

The array element specifies a loadable segment, described by p_filesz and p_memsz. The bytes from the file are mapped to the beginning of the memory segment. If the segment’s memory size p_memsz is larger than the file size p_filesz, the “extra” bytes are defined to hold the value 0 and to follow the segment’s initialized area. The file size may not be larger than the memory size. Loadable segment entries in the program header table appear in ascending order, sorted on the p_vaddr member.

PT_DYNAMIC

The array element specifies dynamic linking information.

PT_INTERP

The array element specifies the location and size of a null-terminated pathname to invoke as an interpreter. This segment type is meaningful only for executable files (though it may occur for shared objects). However it may not occur more than once in a file. If it is present, it must precede any loadable segment entry.

PT_NOTE

The array element specifies the location of notes (ElfN_Nhdr).

PT_SHLIB

This segment type is reserved but has unspecified semantics. Programs that contain an array element of this type do not conform to the ABI.

PT_PHDR

The array element, if present, specifies the location and size of the program header table itself, both in the file and in the memory image of the program. This segment type may not occur more than once in a file. Moreover, it may occur only if the program header table is part of the memory image of the program. If it is present, it must precede any loadable segment entry.

PT_LOPROC, PT_HIPROC

Values in the inclusive range [PT_LOPROC, PT_HIPROC] are reserved for processor-specific semantics.

PT_GNU_STACK

GNU extension which is used by the Linux kernel to control the state of the stack via the flags set in the p_flags member.
从上面的解释可知，只有LOAD flag的段才能被加载到VM中。所以这里能加载的只有序号为02和03的segments。sect我们知道section包含text section、data section、bss section等等。那segment到底是什么呢？

Section和Segment之间的纠葛

segment其实是从加载的视角来看binary，一个segment里可能会包含多个不同section。为什么要这样做呢？
因为VM也算是一种资源。如果加载的时候按section来加载，那可能一个size很小的section因为需要align，到最后可能需要占用一大片空间，会造成严重的浪费。所以加载的时候考虑将多个能合并的section作为一个segment。同一个segment可以连续存放在一起。所以在前面的信息中我们除了能看到segment的属性/地址/size等信息还能看到sections和segments的映射关系。因为我们分析的加载过程，所以这里仅看segments中具有LOAD属性的02和03段。

   02     .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .plt.got .text .fini .rodata .eh_frame_hdr .eh_frame 
   03     .init_array .fini_array .jcr .dynamic .got .got.plt .data .bss

可以看到02段中包含了.init .text .rodata等比较常见的段。在03段中有常见的.data和.bss段。到此开头提出的两个问题就有答案了。1.OS是根据segment信息进行VM布局的。2.进程maps中打印的信息中，VMA并不是和text/data/bss对应。而一个一个VMA中可能有多个section。比如前面看到的.init/.text/.rodata就放在同一个VMA中，.data/.bss也放在同一个VMA中。
因为一个segment会包含多个section。所以也先把binary中sections的信息通过readelf工具先读出来。

binwu@binwu3-DESK2:~/work/hello_world$ readelf -S hello_world
There are 31 section headers, starting at offset 0x1a18:

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] .interp           PROGBITS         0000000000400238  00000238
       000000000000001c  0000000000000000   A       0     0     1
  [ 2] .note.ABI-tag     NOTE             0000000000400254  00000254
       0000000000000020  0000000000000000   A       0     0     4
  [ 3] .note.gnu.build-i NOTE             0000000000400274  00000274
       0000000000000024  0000000000000000   A       0     0     4
  [ 4] .gnu.hash         GNU_HASH         0000000000400298  00000298
       000000000000001c  0000000000000000   A       5     0     8
  [ 5] .dynsym           DYNSYM           00000000004002b8  000002b8
       0000000000000078  0000000000000018   A       6     1     8
  [ 6] .dynstr           STRTAB           0000000000400330  00000330
       0000000000000043  0000000000000000   A       0     0     1
  [ 7] .gnu.version      VERSYM           0000000000400374  00000374
       000000000000000a  0000000000000002   A       5     0     2
  [ 8] .gnu.version_r    VERNEED          0000000000400380  00000380
       0000000000000020  0000000000000000   A       6     1     8
  [ 9] .rela.dyn         RELA             00000000004003a0  000003a0
       0000000000000018  0000000000000018   A       5     0     8
  [10] .rela.plt         RELA             00000000004003b8  000003b8
       0000000000000048  0000000000000018  AI       5    24     8
  [11] .init             PROGBITS         0000000000400400  00000400
       000000000000001a  0000000000000000  AX       0     0     4
  [12] .plt              PROGBITS         0000000000400420  00000420
       0000000000000040  0000000000000010  AX       0     0     16
  [13] .plt.got          PROGBITS         0000000000400460  00000460
       0000000000000008  0000000000000000  AX       0     0     8
  [14] .text             PROGBITS         0000000000400470  00000470
       0000000000000182  0000000000000000  AX       0     0     16
  [15] .fini             PROGBITS         00000000004005f4  000005f4
       0000000000000009  0000000000000000  AX       0     0     4
  [16] .rodata           PROGBITS         0000000000400600  00000600
       0000000000000011  0000000000000000   A       0     0     4
  [17] .eh_frame_hdr     PROGBITS         0000000000400614  00000614
       0000000000000034  0000000000000000   A       0     0     4
  [18] .eh_frame         PROGBITS         0000000000400648  00000648
       00000000000000f4  0000000000000000   A       0     0     8
  [19] .init_array       INIT_ARRAY       0000000000600e10  00000e10
       0000000000000008  0000000000000000  WA       0     0     8
  [20] .fini_array       FINI_ARRAY       0000000000600e18  00000e18
       0000000000000008  0000000000000000  WA       0     0     8
  [21] .jcr              PROGBITS         0000000000600e20  00000e20
       0000000000000008  0000000000000000  WA       0     0     8
  [22] .dynamic          DYNAMIC          0000000000600e28  00000e28
       00000000000001d0  0000000000000010  WA       6     0     8
  [23] .got              PROGBITS         0000000000600ff8  00000ff8
       0000000000000008  0000000000000008  WA       0     0     8
  [24] .got.plt          PROGBITS         0000000000601000  00001000
       0000000000000030  0000000000000008  WA       0     0     8
  [25] .data             PROGBITS         0000000000601030  00001030
       0000000000000010  0000000000000000  WA       0     0     8
  [26] .bss              NOBITS           0000000000601040  00001040
       0000000000000008  0000000000000000  WA       0     0     1
  [27] .comment          PROGBITS         0000000000000000  00001040
       0000000000000035  0000000000000001  MS       0     0     1
  [28] .shstrtab         STRTAB           0000000000000000  00001905
       000000000000010c  0000000000000000           0     0     1
  [29] .symtab           SYMTAB           0000000000000000  00001078
       0000000000000660  0000000000000018          30    47     8
  [30] .strtab           STRTAB           0000000000000000  000016d8
       000000000000022d  0000000000000000           0     0     1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), l (large)
  I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

这里我们能直观的看到Address这个链接地址。把binary加载到VM中就是根据这个地址来搬运的。先看02 segment中对应的section的地址，即从.interp到.eh_frame section的链接地址。观察Address可以发现它们都是一个section接一个section顺序存放的。地址区间为0x400238~0x40073C(0x400648+f4)。这个地址是不是感觉很熟悉？好，把02 segment，/proc/xxx/maps，和sections中所有设计到地址的信息都列在一起观察一下。
sections:
start:0x400238 end:0x40073C
segment:
VirtAddr:0x0000000000400000 Memsize:0x000000000000073C flags：R E
maps:
00400000-00401000 r-xp 00000000 00:31 33562923 /home/binwu/work/hello_world/hello_world
因为1.运行时地址是section中链接的虚拟地址 2.maps中的VMA就是实际进程中的VMA分布。
所以在加载binary时需要根据section的虚拟地址再结合VM地址page对齐，最终才是segment 02对应的VMA实际地址，也就是进程maps中看到的地址。
但是又有一个问题。在segment中只有两个LOAD属性段，但在maps中确有三个VMA。这是怎么回事呢？先看segment 03段中section信息。

   03     .init_array .fini_array .jcr .dynamic .got .got.plt .data .bss

再去找这些section链接时的虚拟地址信息。

  [19] .init_array       INIT_ARRAY       0000000000600e10  00000e10
       0000000000000008  0000000000000000  WA       0     0     8
  [20] .fini_array       FINI_ARRAY       0000000000600e18  00000e18
       0000000000000008  0000000000000000  WA       0     0     8
  [21] .jcr              PROGBITS         0000000000600e20  00000e20
       0000000000000008  0000000000000000  WA       0     0     8
  [22] .dynamic          DYNAMIC          0000000000600e28  00000e28
       00000000000001d0  0000000000000010  WA       6     0     8
  [23] .got              PROGBITS         0000000000600ff8  00000ff8
       0000000000000008  0000000000000008  WA       0     0     8
  [24] .got.plt          PROGBITS         0000000000601000  00001000
       0000000000000030  0000000000000008  WA       0     0     8
  [25] .data             PROGBITS         0000000000601030  00001030
       0000000000000010  0000000000000000  WA       0     0     8
  [26] .bss              NOBITS           0000000000601040  00001040
       0000000000000008  0000000000000000  WA       0     0     1

看Address这列就能发现，其实链接地址就横跨两个page的VM了。因为segment 03的起始地址就已经在600e10了，加上size，一个page的VMA已经放不下了，所以需要两个page的VMA。
这结果看起来好像VMA是按照一个page一个page来分配的？

进程maps中的VMA和segment间的关系

假象，绝对的假象。只是因为这里的segment 03中只读属性的section刚好能存放一个page，剩下rw也能用一个page来存放。所以这里看到segment 03被分别存放到了两个VMA中。我们可以修改测试程序来验证这个结果。

#include<stdio.h>
#include<unistd.h>

int a[1024] = {1};

int main()
{
    printf("hello world!\n");

    while(1) {
        sleep(1);
    }   

    return 0;
}

我们增加了一个数组a[1024]。因为全局已经初始化的变量会被加到data section中，而前面我们的分析可以看到，data section是被放到了segment 03中。所以这样的修改结果就是segment 03占用的空间会变大。按照我们前面的假设，如果VMA是按照一个page一个page来分配，那这个新的hello_world进程maps中应该会多一个VMA出来。运行起来后的maps如下：

bwu@tp430s:~$ ./hello_world &
[1] 4338
bwu@tp430s:~$ hello world!
cat /proc/4338/maps
00400000-00401000 r-xp 00000000 08:07 11406143                           /home/bwu/hello_world
00600000-00601000 r--p 00000000 08:07 11406143                           /home/bwu/hello_world
00601000-00603000 rw-p 00001000 08:07 11406143                           /home/bwu/hello_world
0233d000-0235e000 rw-p 00000000 00:00 0                                  [heap]
7feafb604000-7feafb7c4000 r-xp 00000000 08:07 12058960                   /lib/x86_64-linux-gnu/libc-2.23.so
7feafb7c4000-7feafb9c4000 ---p 001c0000 08:07 12058960                   /lib/x86_64-linux-gnu/libc-2.23.so
7feafb9c4000-7feafb9c8000 r--p 001c0000 08:07 12058960                   /lib/x86_64-linux-gnu/libc-2.23.so
7feafb9c8000-7feafb9ca000 rw-p 001c4000 08:07 12058960                   /lib/x86_64-linux-gnu/libc-2.23.so
7feafb9ca000-7feafb9ce000 rw-p 00000000 00:00 0 
7feafb9ce000-7feafb9f4000 r-xp 00000000 08:07 12058957                   /lib/x86_64-linux-gnu/ld-2.23.so
7feafbbd1000-7feafbbd4000 rw-p 00000000 00:00 0 
7feafbbf3000-7feafbbf4000 r--p 00025000 08:07 12058957                   /lib/x86_64-linux-gnu/ld-2.23.so
7feafbbf4000-7feafbbf5000 rw-p 00026000 08:07 12058957                   /lib/x86_64-linux-gnu/ld-2.23.so
7feafbbf5000-7feafbbf6000 rw-p 00000000 00:00 0 
7ffcbe463000-7ffcbe484000 rw-p 00000000 00:00 0                          [stack]
7ffcbe5cd000-7ffcbe5d0000 r--p 00000000 00:00 0                          [vvar]
7ffcbe5d0000-7ffcbe5d2000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

可以看到VMA的数目并没有变多。但是第三个可读可写属性的VMA确实变大了，而且正好变大一个page。

到此我们应该可以得到文章开头几个问题的答案了。

Linux加载image到VM中是根据image中的segment信息。且只有LOAD type的segment会被加载。
segment和VMA并不是一一对应的关系，一个segment可能对应多个VMA。这是由segment中的section属性决定的。比如前面例子中的segment 03，按照r/rw属性被分布到了两个VMA中。