| View previous topic :: View next topic |
| Author |
Message |
Pramod Subramanyan
Guest
|
 Posted: Fri Oct 17, 2008 9:50 am Post subject: Memory map permissions |
 |
|
Hello everybody,
I'm trying to dump the contents of a process's virtual memory into a
file. I'm getting the mapped regions by reading the /proc/<pid>/maps
file. The interesting thing is, this file shows some regions as having
neither read, nor write, nor execute permissions. For instance:
00400000-00402000 r-xp 00000000 08:03
4547467 /home/pramod/projects/ckpoint/pckpt
00601000-00602000 rw-p 00001000 08:03
4547467 /home/pramod/projects/ckpoint/pckpt
00602000-00624000 rw-p 00602000 00:00
0 [heap]
2b99e4041000-2b99e405e000 r-xp 00000000 08:03
1196043 /lib/ld-2.7.so
2b99e405e000-2b99e4061000 rw-p 2b99e405e000 00:00 0
2b99e425e000-2b99e4260000 rw-p 0001d000 08:03
1196043 /lib/ld-2.7.so
2b99e4260000-2b99e43b8000 r-xp 00000000 08:03
1196252 /lib/libc-2.7.so
2b99e43b8000-2b99e45b8000 ---p 00158000 08:03
1196252 /lib/libc-2.7.so
The second region that is mapped from the /lib/libc-2.7.so has none of
permission bits set. Is this memory that is supposed to be private to
the kernel?
Anyway, so I figured that I'd just give myself read access to this
region by calling mprotect. Unfortunately, this makes mprotect crash,
raising SIGBUS in the process. Now, I did a bit of reading up, and it
appears that SIGBUS can happen if I'm accessing unaligned address, or
if the physical memory can't be addressed. It doesn't look like either
of these things is the problem, so I think I'm missing something here.
What could be going wrong here? What are these inaccessible regions
anyway? Any ideas will be much appreciated.
Thanks in advance,
Pramod |
|
| |
|
 Back to top |
Pramod Subramanyan
Guest
|
| Posted: Fri Oct 17, 2008 4:38 pm Post subject: Re: Memory map permissions |
|
|
On Oct 17, 7:36 pm, John Reiser <jrei...@BitWagon.com> wrote:
| Quote: | I'm trying to dump the contents of a process's virtual memory into a
file.
Check if somebody else has done this already. Look for "unexec" etc.
Also, "if (0==fork()) { raise(SIGSEGV); }" will produce a coredump,
assuming that you have "ulimit -c unlimited". A coreudmp is good enough
in most cases, and sometimes better because gdb already knows how
to interpret a coredump.
I'm getting the mapped regions by reading the /proc/<pid>/maps
file. The interesting thing is, this file shows some regions as having
neither read, nor write, nor execute permissions. For instance:
2b99e43b8000-2b99e45b8000 ---p 00158000 08:03 1196252 /lib/libc-2.7.so
This is a "hole". Apply "readelf --segments /lib/libc-2.7.so" and note
that the mapping of the separate PT_LOAD from the file into the address space
is not contiguous. Some esoteric parts of glibc cannot handle cases where
PT_LOAD from one file get mapped so as to be intermingled with PT_LOAD
from other files. Therefore, ld-linux prevents this, and the mechanism
involves such holes. Read the code in glibc2.7/elf to see how.
Anyway, so I figured that I'd just give myself read access to this
region by calling mprotect. Unfortunately, this makes mprotect crash,
Did mprotect() itself crash? Run under gdb, and show the $pc and traceback.
Anyway, a "hole" literally contains nothing. Do not try to read it.
--
|
You're right. Its not mprotect that's crashing but the subsequent
read. Anyway, all this information is interesting. I think you've
given enough pointers to figure out how to proceed now.
Thanks a lot.
Pramod |
|
| |
|
| Back to top |
John Reiser
Guest
|
| Posted: Fri Oct 17, 2008 7:36 pm Post subject: Re: Memory map permissions |
|
|
| Quote: | I'm trying to dump the contents of a process's virtual memory into a
file.
|
Check if somebody else has done this already. Look for "unexec" etc.
Also, "if (0==fork()) { raise(SIGSEGV); }" will produce a coredump,
assuming that you have "ulimit -c unlimited". A coreudmp is good enough
in most cases, and sometimes better because gdb already knows how
to interpret a coredump.
| Quote: | I'm getting the mapped regions by reading the /proc/<pid>/maps
file. The interesting thing is, this file shows some regions as having
neither read, nor write, nor execute permissions. For instance:
2b99e43b8000-2b99e45b8000 ---p 00158000 08:03 1196252 /lib/libc-2.7.so
|
This is a "hole". Apply "readelf --segments /lib/libc-2.7.so" and note
that the mapping of the separate PT_LOAD from the file into the address space
is not contiguous. Some esoteric parts of glibc cannot handle cases where
PT_LOAD from one file get mapped so as to be intermingled with PT_LOAD
from other files. Therefore, ld-linux prevents this, and the mechanism
involves such holes. Read the code in glibc2.7/elf to see how.
| Quote: | Anyway, so I figured that I'd just give myself read access to this
region by calling mprotect. Unfortunately, this makes mprotect crash,
|
Did mprotect() itself crash? Run under gdb, and show the $pc and traceback.
Anyway, a "hole" literally contains nothing. Do not try to read it.
-- |
|
| |
|
| Back to top |
|
