9

I'm running Arch linux on my laptop, which is kernel 3.12.9 right now. Something has changed about the way the kernel maps in a dynamically-linked executable and I can't figure it out. Here's the example:

% /usr/bin/cat /proc/self/maps ... 00400000-0040b000 r-xp 00000000 08:02 1186756 /usr/bin/cat 0060a000-0060b000 r--p 0000a000 08:02 1186756 /usr/bin/cat 0060b000-0060c000 rw-p 0000b000 08:02 1186756 /usr/bin/cat 00d6c000-00d8d000 rw-p 00000000 00:00 0 [heap] 7f29b3485000-7f29b3623000 r-xp 00000000 08:02 1182988 /usr/lib/libc-2.19.so ...

My question is: what is the third mapping from /usr/bin/cat?

Based on readelf -l /usr/bin/cat, there's a loadable segment of 0x1f8 bytes that should map at 0x400000. There's a loadable segment of 0xae10 bytes at 0x60ae10. Those two pieces of file correspond to the 00400000-0040b000 mapping, and the 0060a000-0060b000 mapping. But the third mapping, which claims to be at a file offset of 0xb000 bytes, doesn't seem to correspond to any Elf64_Phdr. In fact, the elf header only has 2 PT_LOAD segments.

I read through fs/binfm_elf.c in the kernel 3.13.2 source code, and I don't see that the kernel maps in anything other than PT_LOAD segments. If I run strace -o trace.out /usr/bin/cat /proc/self/maps, I don't see any mmap() calls that would map in a piece of /usr/bin/cat, so that 3rd piece is mapped in by the kernel.

I ran the same command (cat /proc/self/maps) on a RHEL server that was running kernel 2.6.18 + RH patches. That only shows 2 pieces of /usr/bin/cat mapped into memory, so this might be new with kernel 3.x.

Improve this question
12
  • Just confirming your findings, I noticed the same differences on CentOS 5 (2.6.18-238.19.1.el5). However on CentOS 6 (2.6.32-358.11.1.el6.x86_64) it too shows the 3 segments. When reading this I also had the thought if this was something to do with SELinux or security in some way. Commented Feb 11, 2014 at 8:20
  • 1
    Isn't that code (.text), read-only data (.rodata), and read-write global data (.data)? Commented Feb 11, 2014 at 18:20
  • @Gilles - if you do readelf -h /usr/bin/cat, you can see that the .text and .rodata sections end up in the first LOAD segment. .data and .bss sections end up in the second LOAD segment. This 3rd mapped segment is something else. Commented Feb 11, 2014 at 18:44
  • 1
    @psusi I'm talking about segment in ELF header, not a memory region. The second LOAD segment splits into two memory regions with r--p and rw-p execute permissions respectively. The question is why does it happen. Commented Dec 12, 2014 at 17:32
  • 1
    @psusi Take a look at this paste. As we can see there are five sections (18-22) which are mapped to the memory region 08054000-08055000 [r--p]. The weird thing is that these sections have WA flags and should be writeable. Commented Dec 15, 2014 at 21:20

2 Answers 2

Reset to default
2

I finally figured this out. The kernel does map only 2 segments. The third piece is a portion of one of the two loaded by the kernel. The run time linker, the program named in the INTERP pheader, which is /usr/lib/ld-2.24.so for me right now, changes the permissions on the mappings using mprotect() so that there are read/write global variables, read-only global variables, and a read/execute text segment. You can see this happen using strace, but it's easy to miss, as it's only a single mprotect() call.

It wasn't a kernel change that caused this, it was a GNU lib C change.

Improve this answer
0

hi i had the same confuse as you, i had dig the internet and find this, i think this is the answer to your confuse too. link: https://stackoverflow.com/questions/33756119/relationship-between-vma-and-elf-segments

for shrot: 

00400000-0040b000 r-xp 00000000 08:02 1186756 /usr/bin/cat **use for store text code and const varibles** 0060a000-0060b000 r--p 0000a000 08:02 1186756 /usr/bin/cat **use for GNU_RELRO relocated info** 0060b000-0060c000 rw-p 0000b000 08:02 1186756 /usr/bin/cat use for bss data segment

hope this useful

Improve this answer

You must log in to answer this question.