linux - 关于Linux中程序的内存布局

Question

我对 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, %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 处更早得到段错误？

Answer 1

我假设您使用 gcc -m32 -nostartfiles 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 到页面的开头。我认为 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) 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 中，但我不知道为什么当前位置不受 .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)，因此出错的第一个地址始终是页面的第一个字节。