linux分段加载程序_关于Linux中程序的内存布局

我假设您使用gcc -m32 -nartartfiles segment-bounds.S或类似的构建它,因此您有一个32位动态二进制文件. (如果您实际使用的是32位系统,则不需要-m32,但大多数想要测试它的人都将使用64位系统.)

我的64位Ubuntu 15.10系统在某些方面给出了与程序略有不同的数字,但整体行为模式是相同的. (不同的内核,或者只是ASLR,解释了这一点.brk地址变化很大,例如,值为0x9354001或0x82a8001)

1) Why is my program starting at address 0x8048190 instead of 0x8048000?

如果构建静态二进制文件,则_start将为0x8048000.

我们可以从readelf -a a.out看到0x8048190是.text部分的开头.但它不是在映射到页面的文本段的开头. (页面是4096B,并且Linux要求映射在文件位置的4096B边界上对齐,因此对于这样布局的文件,execve不可能将_start映射到页面的开头.我认为关闭列是文件中的位置.)

据推测,.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) Why is there a gap between the end of the text section and the start of the data section?

为什么不？它们必须位于可执行文件的不同段中,因此映射到不同的页面. (文本是只读的和可执行的,可以是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) If the system break point is at 0x83b4001,why I get the segmentation fault earlier at 0x804a000?

这告诉我们文本段和brk之间有未映射的页面. (您的循环以ebx = $start_text开头,因此它在文本段之后的第一个未映射页面上出现故障).除了文本和数据之间的虚拟地址空间中的漏洞之外,数据段之外可能还有其他漏洞.

内存保护具有页面粒度(4096B),因此第一个故障地址始终是页面的第一个字节.