关于Linux中程序的内存布局

我对 Linux中程序的内存布局有一些疑问.我从各种来源(我正在阅读“从头开始编程”)中了解到,每个部分都被加载到它自己的内存区域.文本部分首先在虚拟地址0x8048000加载,数据部分在此之后立即加载,接下来是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,%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 -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),因此第一个故障地址始终是页面的第一个字节.

关于Linux中程序的内存布局

解决方法

相关文章