Какова цель кажущихся непригодными отображений памяти в linux?

Прогорклый не имеет ничего общего с крутым. Но на случай, если у кого-то возникнет подобная проблема, это была опция useradd_var_run_t , которая помогала. Итак, команда была такой:

semanage fcontext -a -t useradd_var_run_t 'rancid'
6
25.03.2017, 02:07
1 ответ

Обратите внимание, что есть две области памяти по 2044 КБ с нулевыми разрешениями. Как упоминалось ранее, «представление выполнения» ELF связано с тем, как загрузить исполняемый двоичный файл в память. Когда ld.so добавляет динамические библиотеки, он смотрит на сегменты, помеченные как LOAD (см. «Заголовки программы» и «Сопоставление раздела с сегментом» из команды readelf -a xxx.so). Обычно есть два сегмента LOAD, и между двумя сегментами есть «дыра» (посмотрите на VirtAddr и MemSiz этих двух сегментов), поэтому ld.поэтому намеренно сделает эту дыру недоступной: найдите символ PROT_NONE в _dl_map_object_from_fd в elf / dl-load.c

http://www.cs.stevens.edu/~jschauma/810/elf.html

Это также легко увидеть это как вызов mprotect , используя strace, например strace -f grep -. / proc / self / maps 2> & 1 | less .

open("/lib64/libpcre.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300\25\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=471728, ...}) = 0
mmap(NULL, 2564360, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f0e3ad2a000
mprotect(0x7f0e3ad9c000, 2093056, PROT_NONE) = 0
mmap(0x7f0e3af9b000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x71000) = 0x7f0e3af9b000
close(3)                                = 0

На github есть зеркала репозитория glibc, поэтому поиск PROT_NONE не составлял труда ...

/ * Эта реализация предполагает (как и соответствующая реализация _dl_unmap_segments, в dl -unmap-segment.h), что общие объекты всегда располагаются так, чтобы все сегменты были смежными (или с промежутками между ними, достаточно маленькими, чтобы желательно зарезервировать все целые страницы внутри пробелы с сопоставлениями PROT_NONE вместо разрешения другого использования этих частей адресного пространства). * /

https://github.com/bminor/glibc/blob/73dfd088936b9237599e4ab737c7ae2ea7d710e1/elf/dl-map-segments.h#L21

/ * _dl_map_segments гарантирует, что любые целые страницы в промежутках между сегментами {{1 }} заполнены отображениями PROT_NONE. Таким образом, мы можем просто отменить отображение всего диапазона одним махом. * /

https://github.com/bminor/glibc/blob/73dfd088936b9237599e4ab737c7ae2ea7d710e1/elf/dl-unmap-segments.h#L25

Java

OpenJDKmitted использует сопоставления PROT_NONE для резервирования незарегистрированных адресов пробел (который затем при необходимости фиксируется с помощью вызовов mprotect).

Естественное предположение состоит в том, что ему по какой-то причине нужна непрерывная куча памяти.

Он использует PROT_NONE для резервирования места, пока оно действительно не понадобится.Исходным контекстом этого комментария является обсуждение чрезмерной фиксации виртуальной машины Linux: использование недоступных сопоставлений позволяет избежать каких-либо обязательств со стороны ядра (до тех пор, пока отображение не потребуется и не станет доступным), в случае, если ядро ​​настроено для строгого режима фиксации ].

Если вам интересно, почему необходимо делать это заранее в контексте JVM, примите во внимание, что собственный код, связанный с использованием JNI или его эквивалента, также может использовать mmap.

https://lwn.net/Articles/627728/

7
27.01.2020, 20:27

Теги

Похожие вопросы