Как узнать, какие части физической памяти содержат данные / инструкции каких процессов?

Question

Я хотел бы знать, где код и данные запущенных в данный момент процессов физически размещаются в оперативной памяти.Это должно быть очень информативно, если возможно представить это распределение графически, чтобы отличительные идентификаторы процесса были точками с отличительными цветами.Как и где получить эту информацию?Похоже, / proc не предоставляет его.Должен ли я написать модуль ядра или обычное приложение пользовательского пространства, которое также может получить такую ​​информацию (если да - как?)?

Answer 1

Я на 100% согласен с "почему бы тебе?" комментарии.

Но если вы этого хотите, модуль ядра может сделать это.
Имея виртуальный адрес в текущем адресном пространстве (если вы выполняете системный вызов из процесса, текущего процесса), вы можете перевести его на физический адрес. Используя последовательно макросы pgd_offset_k, pud_offset, pmd_offset, pte_offset, вы сможете получить физический адрес.

@ Ответ Даниэля поможет вам узнать, какие адреса вы хотите.

Вы также можете попробовать использовать mem_map[i].address_space. Он должен содержать некоторую информацию о владельце для каждой физической страницы. Я действительно не знаю, как это понять.

Обратите внимание, что между процессами может быть перекрытие. Такие библиотеки, как libc, которые загружаются несколькими процессами, могут иметь одну копию в физической памяти.

Answer 2

Информация такого рода предоставляется файлом maps.Он представляет отображения памяти всех модулей, которые процесс загрузил в память.

Это информация для моего init, посмотрите:

00400000-00408000 r-xp 00000000 08:02 261498                             /sbin/init
00607000-00608000 r--p 00007000 08:02 261498                             /sbin/init
00608000-00609000 rw-p 00008000 08:02 261498                             /sbin/init
01336000-01357000 rw-p 00000000 00:00 0                                  [heap]
7fa740f1c000-7fa7410b2000 r-xp 00000000 08:02 265802                     /lib/libc-2.15.so
7fa7410b2000-7fa7412b2000 ---p 00196000 08:02 265802                     /lib/libc-2.15.so
7fa7412b2000-7fa7412b6000 r--p 00196000 08:02 265802                     /lib/libc-2.15.so
7fa7412b6000-7fa7412b8000 rw-p 0019a000 08:02 265802                     /lib/libc-2.15.so
7fa7412b8000-7fa7412bc000 rw-p 00000000 00:00 0
7fa7412bc000-7fa7412dd000 r-xp 00000000 08:02 265813                     /lib/ld-2.15.so
7fa7414ce000-7fa7414d1000 rw-p 00000000 00:00 0
7fa7414db000-7fa7414dc000 rw-p 00000000 00:00 0
7fa7414dc000-7fa7414dd000 r--p 00020000 08:02 265813                     /lib/ld-2.15.so
7fa7414dd000-7fa7414de000 rw-p 00021000 08:02 265813                     /lib/ld-2.15.so
7fa7414de000-7fa7414df000 rw-p 00000000 00:00 0
7fffeb8c5000-7fffeb8e6000 rw-p 00000000 00:00 0                          [stack]
7fffeb9ff000-7fffeba00000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

"r--p "- флаги каждой ассоциированной области.«Х» означает, что данный регион содержит исполняемые данные, то есть инструкции.В этом случае мы имеем регион 00400000-00408000, помеченный как доступный только для чтения, исполняемый и закрытый, и сопоставленный с /sbin/init.Следовательно, это место, где хранится раздел .text исполняемого файла.

Answer 3

Вы можете положиться на физические адреса, только если вы заблокируете их в памяти, иначе информация о физических адресах не имеет смысла, так как они часто меняются.Приложение пользовательского пространства не может предоставить информацию о физическом адресе, так как ему нужно читать записи таблицы страниц.вам обязательно нужно написать модуль ядра для него и использовать информацию, предоставленную @Daniel и @ugoren.Вы можете получить больше информации здесь