Что означают разрешения ---p в /proc/self/maps?

Я понимаю значение битов rwxps. r-xp для .text. rw-p для .data/.bss/heap/stack. Какая польза от ---p страниц?

Например, посмотрите этот вывод 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]

linux permissions memory shared-libraries memory-mapping
person user209051    schedule 05.10.2010    source источник
comment
См. ответ здесь: stackoverflow.com/questions/16524895/   -  person Enyby    schedule 07.07.2015

Ответы (2)


arrow_upward
2
arrow_downward

Согласно справочной странице, это означает "частное" (копирование при записи). Однако понятия не имею, в чем польза такого сопоставления, если в нем нет возможности читать/записывать/выполнять что-либо.

Возможно, он является приватным для libc, что позволяет ему изменять разрешения на доступ к нему без того, чтобы пользовательская программа случайно его испортила.

person Jonathan    schedule 06.10.2010
comment
Я думаю, что это так, потому что если программе нужно изменить копию libc, которую она использовала, то измененная libc будет повторно отображена в пространстве памяти этого процесса, так что она останется неизменной для других процессов. - person Dio; 10.06.2015

arrow_upward
0
arrow_downward

Это то, что я тоже задавался вопросом о специфике. Он не появлялся до тех пор, пока в последние несколько лет, но я не уверен, виноват ли GNU binutils или динамический компоновщик glibc (ld-linux.so.2) за это изменение.

Сначала я подумал, что это своего рода защитная область, созданная динамическим компоновщиком для защиты от доступа извне к сегменту данных библиотеки, но нет смысла делать ее такой большой. Возможно, это полная карта файла библиотеки while, чтобы динамический компоновщик мог снова сделать его доступным для чтения в какой-то момент в будущем (возможно, во время вызовов dlopen или dlsym) для доступа к метаданным ELF, которые обычно не нужно отображать.

В любом случае, это неприятное раздувание, особенно на 32-битных машинах, где виртуальное адресное пространство является ценным ресурсом. Он также раздувает таблицы страниц ядра, увеличивая ресурсы пространства ядра, используемые процессом.

P.S. Извините, это не совсем ответ. Я знаю, что это просто случайные фрагменты, которые могут помочь найти ответ, но это было слишком долго для комментария.

person R.. GitHub STOP HELPING ICE    schedule 14.06.2011