Re: About reading /proc/*/mem

Richard F Weber
2001-05-02T11:11:55Z

[-- Attachment #1: Type: text/plain, Size: 2042 bytes --]

Alexander Viro wrote:

>
>On 1 May 2001, Eric W. Biederman wrote:
>
>>>Unfortunately, ptrace() probobally isn't going to allow me to do that.
>>>So my next question is does opening /proc/*/mem force the child process
>>>to stop on every interrupt (just like ptrace?)
>>>
>>
>>The not stopping the child should be the major difference between
>>/proc/*/mem and ptrace.
>>
>
>Could somebody tell me what would one do with data read from memory
>of process that is currently running?
>
After doing some digging around, I found this URL: (Sorry, the
original page at nsa seems to have disappeared).

http://www.google.com/search?q=cache:nsa.gov/selinux/slinux-200101020953/node57.html+access+physical+memory+/proc+/mem&hl=en

In any case, it indicates the the /proc/*/mem file can only be read by
the process itself on the fly, or by a parent process that has stopped
execution of the child via SIGSTOP. So it seems so far that the
behavior of /proc/*/mem is exactly the same as the behavior of ptrace in
that it forces stoppage of execution in order to read memory.
Bummer.(Or has this changed from v 2.2.x to v2.4.x?)

So how else can I access the process memory? I'm wondering if it'd be
feasible to hack the kernel to add an extra ptrace_nostop() fn that
would allow ptracing without forcing a stop in the process. I'd really
rather not have to hack the kernel unless I really have to though.

My second thought is again going back to finding the translation of
where the process physically lives in the virtual memory itself. So
this way I can just go and directly look at the memory of the process.
But then this runs into problems as to finding where that process lives,
and being told my thoughts on this are totally wrong.

I suppose the question is I know the process exists, I know the process
is pinned into memory so it can't get swapped out, I just need to know
how to translate the process's virtual address of 0x080495998 to some
chunk of physical memory, and then take a look at it.

Thanks.

--Rich

[-- Attachment #2: Type: text/html, Size: 2679 bytes --]