What do the "---p" permissions in /proc/self/maps mean?

Question

I understand the meaning of rwxps bits. r-xp is for .text. rw-p is for .data/.bss/heap/stack. What is the use of just ---p pages?

For example see this output of cat /proc/self/maps

00400000-0040b000 r-xp 00000000 08:03 827490                             /bin/cat
0060b000-0060c000 rw-p 0000b000 08:03 827490                             /bin/cat
0060c000-0062d000 rw-p 00000000 00:00 0                                  [heap]
3819a00000-3819a1e000 r-xp 00000000 08:03 532487                         /lib64  ld-2.11.2.so
3819c1d000-3819c1e000 r--p 0001d000 08:03 532487                         /lib64/ld-2.11.2.so
3819c1e000-3819c1f000 rw-p 0001e000 08:03 532487                         /lib64/ld-2.11.2.so
3819c1f000-3819c20000 rw-p 00000000 00:00 0 
3819e00000-3819f70000 r-xp 00000000 08:03 532490                         /lib64/libc-2.11.2.so
3819f70000-381a16f000 ---p 00170000 08:03 532490                         /lib64/libc-2.11.2.so
381a16f000-381a173000 r--p 0016f000 08:03 532490                         /lib64/libc-2.11.2.so
381a173000-381a174000 rw-p 00173000 08:03 532490                         /lib64/libc-2.11.2.so
381a174000-381a179000 rw-p 00000000 00:00 0 
7fb859c49000-7fb85fa7a000 r--p 00000000 08:03 192261                     /usr/lib/locale/locale-archive
7fb85fa7a000-7fb85fa7d000 rw-p 00000000 00:00 0 
7fb85fa95000-7fb85fa96000 rw-p 00000000 00:00 0
7fff64894000-7fff648a9000 rw-p 00000000 00:00 0                          [stack]
7fff649ff000-7fff64a00000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

Answer 1

According to the man page, it means private (copy on write). No idea what the usefulness of such a mapping is without being able to read/write/execute anything in it, though.

Possibly it is private to libc, allowing it to modify the permissions to access it without a user program accidentally mucking it up.

Answer 2

This is something I've wondered about the specifics of too. It didn't appear until sometime in the last few years, but I'm unsure whether GNU binutils or the glibc dynamic linker (ld-linux.so.2) is responsible for the change.

At first I thought it was a sort of guard region created by the dynamic linker to protect against out of bounds access to a library's data segment, but it makes no sense for it to be so large. It's possible that it's a complete map of the while library file so that the dynamic linker can make it readable again at some time in the future (perhaps during dlopen or dlsym calls) to access ELF metadata that doesn't normally need to be mapped.

In any case, it's nasty bloat, especially on 32-bit machines where virtual address space is a precious resource. It also bloats the kernel page tables, increasing the kernelspace resources used by a process.

P.S. Sorry this isn't really an answer. I know it's just random bits and pieces that might help lead to an answer, but it was way too long for a comment.

Answer 3

Private mapping (MAP_PRIVATE): Modifications to the contents of the mapping are not visible to other processes.

For file mapping they are not carried through to the underlying file. Changes to the contents of the mapping are nevertheless private to each process.

The kernel accomplishes this by using the copy-on-write technique. This means that whenever a process attempts to modify the contents of a page, the kernel first creates a new, separate copy of that page for the process (and adjusts the process’s page tables).

For this reason, a MAP_PRIVATE mapping is sometimes referred to as a private, copy-on-write mapping. (Source: The Linux Programming Interface book)