1

My final goal is to create a new system call which returns the range of each segment of the current thread.

The segments:

  1. text segment
  2. data segment
  3. BSS segment
  4. heap segment
  5. memory mapping segment (shared libraries)
  6. stack segment

I would like to start from understanding the /proc/$pid/maps first.

The Enviroment:

  • Ubuntu 22.04
  • Linux 5.15.74
555555554000-555555556000 r--p 00000000 08:02 7873545                    /home/vm/Desktop/test
555555556000-555555557000 r-xp 00002000 08:02 7873545                    /home/vm/Desktop/test
555555557000-555555558000 r--p 00003000 08:02 7873545                    /home/vm/Desktop/test
555555558000-555555559000 r--p 00003000 08:02 7873545                    /home/vm/Desktop/test
555555559000-55555555a000 rw-p 00004000 08:02 7873545                    /home/vm/Desktop/test
55555555a000-55555557b000 rw-p 00000000 00:00 0                          [heap]
7ffff7a50000-7ffff7a54000 rw-p 00000000 00:00 0
7ffff7a54000-7ffff7a62000 r--p 00000000 08:02 3152581                    /usr/lib/x86_64-linux-gnu/libm.so.6
7ffff7a62000-7ffff7ade000 r-xp 0000e000 08:02 3152581                    /usr/lib/x86_64-linux-gnu/libm.so.6
7ffff7ade000-7ffff7b39000 r--p 0008a000 08:02 3152581                    /usr/lib/x86_64-linux-gnu/libm.so.6
7ffff7b39000-7ffff7b3a000 r--p 000e4000 08:02 3152581                    /usr/lib/x86_64-linux-gnu/libm.so.6
7ffff7b3a000-7ffff7b3b000 rw-p 000e5000 08:02 3152581                    /usr/lib/x86_64-linux-gnu/libm.so.6
7ffff7b3b000-7ffff7b63000 r--p 00000000 08:02 3151930                    /usr/lib/x86_64-linux-gnu/libc.so.6
7ffff7b63000-7ffff7cf8000 r-xp 00028000 08:02 3151930                    /usr/lib/x86_64-linux-gnu/libc.so.6
7ffff7cf8000-7ffff7d50000 r--p 001bd000 08:02 3151930                    /usr/lib/x86_64-linux-gnu/libc.so.6
7ffff7d50000-7ffff7d54000 r--p 00214000 08:02 3151930                    /usr/lib/x86_64-linux-gnu/libc.so.6
7ffff7d54000-7ffff7d56000 rw-p 00218000 08:02 3151930                    /usr/lib/x86_64-linux-gnu/libc.so.6
7ffff7d56000-7ffff7d63000 rw-p 00000000 00:00 0
7ffff7d63000-7ffff7d66000 r--p 00000000 08:02 3145850                    /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
7ffff7d66000-7ffff7d7d000 r-xp 00003000 08:02 3145850                    /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
7ffff7d7d000-7ffff7d81000 r--p 0001a000 08:02 3145850                    /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
7ffff7d81000-7ffff7d82000 r--p 0001d000 08:02 3145850                    /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
7ffff7d82000-7ffff7d83000 rw-p 0001e000 08:02 3145850                    /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
7ffff7d83000-7ffff7e1d000 r--p 00000000 08:02 3145846                    /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30
7ffff7e1d000-7ffff7f2d000 r-xp 0009a000 08:02 3145846                    /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30
7ffff7f2d000-7ffff7f9c000 r--p 001aa000 08:02 3145846                    /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30
7ffff7f9c000-7ffff7fa7000 r--p 00218000 08:02 3145846                    /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30
7ffff7fa7000-7ffff7faa000 rw-p 00223000 08:02 3145846                    /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30
7ffff7faa000-7ffff7fad000 rw-p 00000000 00:00 0
7ffff7fbb000-7ffff7fbd000 rw-p 00000000 00:00 0
7ffff7fbd000-7ffff7fc1000 r--p 00000000 00:00 0                          [vvar]
7ffff7fc1000-7ffff7fc3000 r-xp 00000000 00:00 0                          [vdso]
7ffff7fc3000-7ffff7fc5000 r--p 00000000 08:02 3151595                    /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
7ffff7fc5000-7ffff7fef000 r-xp 00002000 08:02 3151595                    /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
7ffff7fef000-7ffff7ffa000 r--p 0002c000 08:02 3151595                    /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
7ffff7ffb000-7ffff7ffd000 r--p 00037000 08:02 3151595                    /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
7ffff7ffd000-7ffff7fff000 rw-p 00039000 08:02 3151595                    /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
7ffffffde000-7ffffffff000 rw-p 00000000 00:00 0                          [stack]
ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0                  [vsyscall]

Below is from my understanding, but I'm not sure if it's correct:

  • text: 555555556000-555555557000
  • data: 555555559000-55555555a000
  • bss: where???
  • heap: 55555555a000-55555557b000
  • memory mapping: Is 7ffff7a54000-7ffff7fff000 correct? or should i exclude [vvar] and [vdso]
  • stack: 7ffffffde000-7ffffffff000

And what are 555555554000-555555556000, 555555557000-555555558000, 555555558000-555555559000 ?

I have read many posts explaining the proc maps, but still feel so confused.

Hare Shinohara
  • 11
  • 1
  • 1
  • These distinctions are made when the process loader is loading from the executable file, but I don't think the kernel tracks them after the process is loaded. – Barmar Oct 27 '22 at 21:25
  • The kernel has no idea what segments relate to which virtual memory areas. That information is only useful to the loader to correctly load the ELF in memory, apply the right permissions etc. The kernel has an ELF loader too, but the information about sections is not kept after it loads an ELF executable in memory. See also [this answer of mine](https://stackoverflow.com/a/72469073/3889449). – Marco Bonelli Oct 27 '22 at 22:41
  • Re: *"And what are 555555554000-555555556000, 555555557000-555555558000, 555555558000-555555559000"* - probably also data/bss/rodata. Sections can span more than one memory page. – Marco Bonelli Oct 27 '22 at 22:42
  • @MarcoBonelli thanks for the reply. You mentioned that the kernel doesn't know the relation between segments and VMAs, however I found some fields in the `mm_struct` data structure look "suspicious", like `start_code`, `end_code`, `start_data`, `end_data`, `start_brk`, `end_brk`, `start_stack` ... Are they reliable? – Hare Shinohara Oct 28 '22 at 08:13
  • @MarcoBonelli But "555555554000-555555556000, 555555557000-555555558000, 555555558000-555555559000" are read-only, shouldn't data/bss segments be writable? – Hare Shinohara Oct 28 '22 at 08:15
  • @HareShinohara those are somewhat related to sections, but there is no 1:1 correspondence. For example, `start_code` and `end_code` concern any executable section in the binary, so while the actual code might be in there, they do not represent the start and end of `.text`. Same goes for `start_data` and `end_data`. AFAIK read-only sections like `.rodata` are not accounted for in `mm_struct`. Stack and brk have nothing to do with sections regardless. As per those addresses, `.rodata` is read only, so it could be that, can't say for sure without looking at the ELF though. – Marco Bonelli Oct 28 '22 at 10:43

0 Answers0