关于Linux中程序的内存布局

我有一些关于Linux中的程序的内存布局的问题。 我知道从各种来源(我正在读“从头开始编程”),每个部分都加载到它自己的内存区域。 文本部分首先在虚拟地址0x8048000处加载,之后立即加载数据部分,接下来是bss部分,然后是堆和堆栈。

为了试验我在assembly中制作这个程序的布局。 首先打印一些标签的地址并计算系统断点。 然后它进入一个无限循环。 循环递增一个指针,然后尝试访问该地址的内存,在某个点分段错误将退出程序(我故意这样做)。

这是该计划:

.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 32bit):

 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处得到分段错误?

我假设你正在用gcc -m32 -nostartfiles segment-bounds.S或类似的方式构建这个,所以你有一个32位的动态二进制文件。 (如果您实际使用的是32位系统,则不需要-m32 ,但大多数要测试此功能的人将拥有64位系统。)

我的64位Ubuntu 15.10系统给你的程序提供了几个不同的数字,但总的行为模式是一样的。 (不同的内核,或只是ASLR ,解释这个0x9354001地址变化很大,例如,值为0x93540010x82a8001


1)为什么我的程序从地址0x8048190而不是0x8048000开始?

如果您构建一个静态二进制文件,您的_start将在0x8048000。

我们可以从readelf -a a.out看到, readelf -a a.out 0x8048190是.text部分的开头。 但是这不是在映射到页面的文本段的开始处。 (页面是4096B,Linux需要映射到文件位置的4096B边界上,所以用这种方式放置的文件, execve不可能将_start映射到页面的起始处。列在文件中的位置。)

假设文本段之前的文本段中的其他部分是动态链接器所需的只读数据,因此将其映射到同一页面的内存中是有意义的。

 ## 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),所以第一个故障地址将始终是页面的第一个字节。