Re: About reading /proc/*/mem

["Richard F Weber" <rfweber@link.com>]

[-- 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 --]