关于Linux中程序的内存布局
Posted
技术标签:
【中文标题】关于Linux中程序的内存布局【英文标题】：About the memory layout of programs in Linux 【发布时间】：2016-12-15 19:59:42 【问题描述】：我对 Linux 中程序的内存布局有一些疑问。我从各种来源（我正在阅读“从头开始编程”）知道每个部分都加载到它自己的内存区域中。 text 部分首先加载到虚拟地址 0x8048000，然后立即加载 data 部分，接下来是 bss 部分，然后是堆和堆栈。
为了试验布局，我在汇编中制作了这个程序。首先它打印一些标签的地址并计算系统断点。然后它进入一个无限循环。循环增加一个指针，然后尝试访问该地址处的内存，在某些时候分段错误将退出程序（我是故意这样做的）。
这是程序：
.section .data
start_data:
str_mem_access:
.ascii "Accessing address: 0x%x\n\0"
str_data_start:
.ascii "Data section start at: 0x%x\n\0"
str_data_end:
.ascii "Data section ends at: 0x%x\n\0"
str_bss_start:
.ascii "bss section starts at: 0x%x\n\0"
str_bss_end:
.ascii "bss section ends at: 0x%x\n\0"
str_text_start:
.ascii "text section starts at: 0x%x\n\0"
str_text_end:
.ascii "text section ends at: 0x%x\n\0"
str_break:
.ascii "break at: 0x%x\n\0"
end_data:
.section .bss
start_bss:
.lcomm buffer, 500
.lcomm buffer2, 250
end_bss:
.section .text
start_text:
.globl _start
_start:
# print address of start_text label
pushl $start_text
pushl $str_text_start
call printf
addl $8, %esp
# print address of end_text label
pushl $end_text
pushl $str_text_end
call printf
addl $8, %esp
# print address of start_data label
pushl $start_data
pushl $str_data_start
call printf
addl $8, %esp
# print address of end_data label
pushl $end_data
pushl $str_data_end
call printf
addl $8, %esp
# print address of start_bss label
pushl $start_bss
pushl $str_bss_start
call printf
addl $8, %esp
# print address of end_bss label
pushl $end_bss
pushl $str_bss_end
call printf
addl $8, %esp
# get last usable virtual memory address
movl $45, %eax
movl $0, %ebx
int $0x80
incl %eax # system break address
# print system break
pushl %eax
pushl $str_break
call printf
addl $4, %esp
movl $start_text, %ebx
loop:
# print address
pushl %ebx
pushl $str_mem_access
call printf
addl $8, %esp
# access address
# segmentation fault here
movb (%ebx), %dl
incl %ebx
jmp loop
end_loop:
movl $1, %eax
movl $0, %ebx
int $0x80
end_text:
这是输出的相关部分（这是 Debian 32 位）：
text section starts at: 0x8048190
text section ends at: 0x804823b
Data section start at: 0x80492ec
Data section ends at: 0x80493c0
bss section starts at: 0x80493c0
bss section ends at: 0x80493c0
break at: 0x83b4001
Accessing address: 0x8048190
Accessing address: 0x8048191
Accessing address: 0x8048192
[...]
Accessing address: 0x8049fff
Accessing address: 0x804a000
Violación de segmento
我的问题是：
1) 为什么我的程序从地址 0x8048190 而不是 0x8048000 开始？有了这个，我猜“_start”标签处的指令不是首先要加载的，那么地址 0x8048000 和 0x8048190 之间是什么？
2) 为什么文本部分的结尾和数据部分的开头之间有间隙？
3) bss 起始地址和结束地址相同。我假设这两个缓冲区存储在其他地方，这是正确的吗？
4) 如果系统断点在 0x83b4001，为什么我早先在 0x804a000 得到分段错误？
【问题讨论】：
几乎完全跑题了，如果你从来没有read this, take a look at it -- 这是一本很棒的书。 请注意，ELF 加载器只关心可执行文件的 segments。在许多情况下存在 1:1 映射，例如.text 部分（链接后）是文本段中的唯一内容。链接器将.rodata 之类的部分组合成.text。此外，“堆”并不是真正存在的东西，而更像是一个概念（使用 mmap(MAP_ANONYMOUS) 的分配与brk 不连续）。我不确定人们是否将 BSS 和静态数据视为堆的一部分。也不确定 Linux 是否将初始 brk 放在 BSS 之后。
【参考方案1】：
我假设您正在使用 gcc -m32 -nostartfiles segment-bounds.S 或类似名称构建它，因此您有一个 32 位动态二进制文件。 （如果您实际使用的是 32 位系统，则不需要 -m32，但大多数想要测试它的人将使用 64 位系统。）
我的 64 位 Ubuntu 15.10 系统提供的数字与您的程序略有不同，但总体行为模式是相同的。 （不同的内核，或者只是ASLR，解释了这一点。brk 地址变化很大，例如，像0x9354001 或0x82a8001 这样的值）
1) 为什么我的程序从地址 0x8048190 而不是 0x8048000 开始？
如果您构建静态二进制文件，您的 _start 将位于 0x8048000。
我们可以从readelf -a a.out 看到0x8048190 是.text 部分的开始。但它不在映射到页面的文本段的开头。 （页面为 4096B，Linux 要求映射在文件位置的 4096B 边界上对齐，因此以这种方式布置文件，execve 不可能将_start 映射到页面的开头。我认为 Off 列是文件中的位置。）
可能.text 部分之前的文本段中的其他部分是动态链接器所需的只读数据，因此将其映射到同一页面中的内存是有意义的。
## part of readelf -a output
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .interp PROGBITS 08048114 000114 000013 00 A 0 0 1
[ 2] .note.gnu.build-i NOTE 08048128 000128 000024 00 A 0 0 4
[ 3] .gnu.hash GNU_HASH 0804814c 00014c 000018 04 A 4 0 4
[ 4] .dynsym DYNSYM 08048164 000164 000020 10 A 5 1 4
[ 5] .dynstr STRTAB 08048184 000184 00001c 00 A 0 0 1
[ 6] .gnu.version VERSYM 080481a0 0001a0 000004 02 A 4 0 2
[ 7] .gnu.version_r VERNEED 080481a4 0001a4 000020 00 A 5 1 4
[ 8] .rel.plt REL 080481c4 0001c4 000008 08 AI 4 9 4
[ 9] .plt PROGBITS 080481d0 0001d0 000020 04 AX 0 0 16
[10] .text PROGBITS 080481f0 0001f0 0000ad 00 AX 0 0 1 ########## The .text section
[11] .eh_frame PROGBITS 080482a0 0002a0 000000 00 A 0 0 4
[12] .dynamic DYNAMIC 08049f60 000f60 0000a0 08 WA 5 0 4
[13] .got.plt PROGBITS 0804a000 001000 000010 04 WA 0 0 4
[14] .data PROGBITS 0804a010 001010 0000d4 00 WA 0 0 1
[15] .bss NOBITS 0804a0e8 0010e4 0002f4 00 WA 0 0 8
[16] .shstrtab STRTAB 00000000 0010e4 0000a2 00 0 0 1
[17] .symtab SYMTAB 00000000 001188 0002b0 10 18 38 4
[18] .strtab STRTAB 00000000 001438 000123 00 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
2) 为什么文本部分的结尾和数据部分的开头之间有间隙？
为什么不呢？它们必须位于可执行文件的不同段中，因此映射到不同的页面。 （文本是只读和可执行的，可以是 MAP_SHARED。数据是读写的，必须是 MAP_PRIVATE。顺便说一句，在 Linux 中，默认情况下数据也是可执行的。）
为动态链接器留出空间将共享库的文本段映射到可执行文件的文本旁边。这也意味着数据部分的越界数组索引更有可能出现段错误。 （更早且更嘈杂的故障总是更容易调试）。
3) bss 起始地址和结束地址相同。我假设这两个缓冲区存储在其他地方，这是正确的吗？
这很有趣。他们在 bss 中，但是 IDK 为什么当前位置不受 .lcomm 标签的影响。可能他们在链接之前进入了不同的小节，因为您使用了.lcomm 而不是.comm。如果我使用 .skip 或 .zero 来预留空间，我会得到你期望的结果：
.section .bss
start_bss:
#.lcomm buffer, 500
#.lcomm buffer2, 250
buffer: .skip 500
buffer2: .skip 250
end_bss:
.lcomm 将内容放入 BSS，即使您不切换到该部分。即它不关心当前部分是什么，并且可能不关心或影响.bss 部分中的当前位置。 TL:DR：当您手动切换到.bss 时，请使用.zero 或.skip，而不是.comm 或.lcomm。
4) 如果系统断点在 0x83b4001，为什么我早先在 0x804a000 得到分段错误？
这告诉我们在文本段和 brk 之间存在未映射的页面。 （您的循环以ebx = $start_text 开头，因此它在文本段之后的第一个未映射页面上出现故障）。除了文本和数据之间的虚拟地址空间中的漏洞之外，可能还有数据段之外的其他漏洞。
内存保护具有页面粒度 (4096B)，因此第一个出错地址将始终是页面的第一个字节。
【讨论】：
我在 Debian 3.5 i386 虚拟机中使用as break.S -o break.o && ld -dynamic-linker /lib/ld-linux.so.2 -o break break.o -lc 构建它（主机是 Ubuntu 15.10 64 位）。
@saga.x：是的，这相当于gcc -m32 -nostartfiles。为什么要为 32 位 VM 烦恼？只需在您的 Ubuntu 系统上使用 gcc -m32 或 as 和 ld with the right args，就像我在链接的那个答案中解释的那样。在 64 位内核上运行 32 位代码可以完美运行，Ubuntu 的 multilib 包包含所有必要的 32 位库。
好的，我安装了gcc-multilib 包并用gcc -m32 -nostartfiles 构建它，它可以工作。我还搜索了一些关于 ASLR 的内容，如果我以 root sysctl -w kernel.randomize_va_space=0 执行，断点地址永远不会改变，它固定在 0x804a001，这与我得到的分段错误的地址相同。我应该阅读更多关于 Linux 工作原理和内存管理的内容，以更好地理解这个主题，非常有趣，但我对此并不陌生。感谢您的回答！
@saga.x：是的，您可以禁用 ASLR，但在使用 gdb 和 /proc/pid/maps 进行调试时，您通常不需要运行之间的重复性。有趣的是，它恰好使用与没有 ASLR 的 32 位内核相同的 brk。但是，32 位和 64 位内核之间存在差异：IIRC，64 位内核下的 32 位进程可以使用整个 4GiB 的虚拟地址空间，但 32 位内核保留每个进程虚拟地址的高 1 或 2GiB在系统调用期间映射内核内存的地址空间。 （因此，在 32 位内核上的 32 位进程中，您最多只能分配 3GiB。）
是的，有很多东西要理解！自从 AMD64 出现之前（现在将近 20 年），我就一直使用 Linux 作为我的桌面，所以我已经能够逐渐掌握很多东西，而不是一次拥有所有的复杂性。在我开始认真地弄乱 asm 之前，我已经知道了很多东西。无论如何，您的问题比通常无聊的“我对 asm 什么都不懂，但我编写了这个程序。为我调试”这类我们在 SO 上看到很多的问题要好得多.继续有趣的问题:)以上是关于关于Linux中程序的内存布局的主要内容，如果未能解决你的问题，请参考以下文章