Hopefully a simple question on /proc/pid/mem

Hopefully a simple question on /proc/pid/mem

[Richard F Weber]

Hopefully this is a simple question.  I'm trying to work on an external 
debugger that can bind to an external process, and open up memory 
locations on the heap to allow reading of data.

Now I've tried using ptrace(), mmap() & lseek/read all with no success.  
The closest I've been able to get is to use ptrace() to do an attach to 
the target process, but couldn't read much of anything from it.  Plus 
I've seen tons of conflicting reports saying that each on is the best, 
and the other two are deprecated.

So what I'd appreciate help in is:

1) Which approach to use?
2) Maybe a sample program that lets me read address 0x8000000 from 
another process.  I know this address is an integer, but I can't ever 
mmap, read or do a PEEKDATA on it.


Thanks in Advance to any pointers or help you can provide.I can provide 
sample code to stuff I've tried, or any other information if it will 
help.  Thanks.

--Rich

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: Hopefully a simple question on /proc/pid/mem

[Stephen C. Tweedie]

Hi,

On Mon, Apr 30, 2001 at 02:17:13PM -0400, Richard F Weber wrote:
> Hopefully this is a simple question.  I'm trying to work on an external 
> debugger that can bind to an external process, and open up memory 
> locations on the heap to allow reading of data.
> 
> Now I've tried using ptrace(), mmap() & lseek/read all with no success.  
> The closest I've been able to get is to use ptrace() to do an attach to 
> the target process, but couldn't read much of anything from it.

ptrace is what other debuggers use.  It really ought to work.

Cheers,
 Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: Hopefully a simple question on /proc/pid/mem

[Alexander Viro]

On Mon, 30 Apr 2001, Stephen C. Tweedie wrote:

> > Now I've tried using ptrace(), mmap() & lseek/read all with no success.  
> > The closest I've been able to get is to use ptrace() to do an attach to 
> > the target process, but couldn't read much of anything from it.
> 
> ptrace is what other debuggers use.  It really ought to work.

I wonder what's wrong with reading from /proc/<pid>/mem, though - it's
using the same code as ptrace.

Al, considering adding /proc/<pid>/{regs,fpregs,ctl} and moving ptrace()
entirely to userland...

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: Hopefully a simple question on /proc/pid/mem

[Benjamin C.R. LaHaise]

On Mon, 30 Apr 2001, Alexander Viro wrote:

> I wonder what's wrong with reading from /proc/<pid>/mem, though - it's
> using the same code as ptrace.

We can actually do this cleanly now that we have proper page_dirty
semantics for raw io.  The original reason for disabling /proc/*/mem was
that it left big gaping holes in the mm code in 2.0, and it hasn't been
repaired since.

		-ben

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: Hopefully a simple question on /proc/pid/mem

[Alexander Viro]

On Mon, 30 Apr 2001, Benjamin C.R. LaHaise wrote:

> On Mon, 30 Apr 2001, Alexander Viro wrote:
> 
> > I wonder what's wrong with reading from /proc/<pid>/mem, though - it's
> > using the same code as ptrace.
> 
> We can actually do this cleanly now that we have proper page_dirty
> semantics for raw io.  The original reason for disabling /proc/*/mem was
> that it left big gaping holes in the mm code in 2.0, and it hasn't been
> repaired since.

ITYM "disabling _write_ on /proc/*/mem". Read is OK. Anyway, current
mem_write() uses the same code as PTRACE_POKEDATA, so if the latter works,
the former also should be OK.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: Hopefully a simple question on /proc/pid/mem

[Benjamin C.R. LaHaise]

On Mon, 30 Apr 2001, Alexander Viro wrote:

> ITYM "disabling _write_ on /proc/*/mem". Read is OK. Anyway, current
> mem_write() uses the same code as PTRACE_POKEDATA, so if the latter works,
> the former also should be OK.

Actually, even read on /proc/*/mem caused problems in 2.0: the elevated
usage could would prevent memory from being reclaimed by the swapper
properly.  Things are so much better now it's not even funny.

		-ben

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: Hopefully a simple question on /proc/pid/mem

[Alexander Viro]

On Mon, 30 Apr 2001, Benjamin C.R. LaHaise wrote:

> On Mon, 30 Apr 2001, Alexander Viro wrote:
> 
> > ITYM "disabling _write_ on /proc/*/mem". Read is OK. Anyway, current
> > mem_write() uses the same code as PTRACE_POKEDATA, so if the latter works,
> > the former also should be OK.
> 
> Actually, even read on /proc/*/mem caused problems in 2.0: the elevated
> usage could would prevent memory from being reclaimed by the swapper
> properly.  Things are so much better now it's not even funny.

ISTR removing some rather nasty code during the procfs rewrite. From
mem_read() and mem_write() - basically, made them wrappers around
access_process_vm().

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: Hopefully a simple question on /proc/pid/mem

[Stephen C. Tweedie]

Hi,

On Mon, Apr 30, 2001 at 03:02:40PM -0400, Benjamin C.R. LaHaise wrote:
> On Mon, 30 Apr 2001, Alexander Viro wrote:
> 
> > I wonder what's wrong with reading from /proc/<pid>/mem, though - it's
> > using the same code as ptrace.
> 
> We can actually do this cleanly now that we have proper page_dirty
> semantics for raw io.  The original reason for disabling /proc/*/mem was
> that it left big gaping holes in the mm code in 2.0, and it hasn't been
> repaired since.

It was mmap of /proc/*/mem which was busted.  read/write should be OK.

Hint: think about what happens if you make a shared mapping of a
private proc/*/mem region... 

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: Hopefully a simple question on /proc/pid/mem

[Eric W. Biederman]

"Stephen C. Tweedie" <sct@redhat.com> writes:

> Hi,
> 
> On Mon, Apr 30, 2001 at 03:02:40PM -0400, Benjamin C.R. LaHaise wrote:
> > On Mon, 30 Apr 2001, Alexander Viro wrote:
> > 
> > > I wonder what's wrong with reading from /proc/<pid>/mem, though - it's
> > > using the same code as ptrace.
> > 
> > We can actually do this cleanly now that we have proper page_dirty
> > semantics for raw io.  The original reason for disabling /proc/*/mem was
> > that it left big gaping holes in the mm code in 2.0, and it hasn't been
> > repaired since.
> 
> It was mmap of /proc/*/mem which was busted.  read/write should be OK.
> 
> Hint: think about what happens if you make a shared mapping of a
> private proc/*/mem region... 

Now that we have reusable swap cache pages we could make it work
correctly, except for the case of the first write a private mapping of
file.    Not that we would want to...

Eric
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: Hopefully a simple question on /proc/pid/mem

[Stephen C. Tweedie]

Hi,

On Mon, Apr 30, 2001 at 07:13:53PM -0600, Eric W. Biederman wrote:

> > Hint: think about what happens if you make a shared mapping of a
> > private proc/*/mem region... 
> 
> Now that we have reusable swap cache pages we could make it work
> correctly, except for the case of the first write a private mapping of
> file.    Not that we would want to...

Think about fork.  If a parent forks and then touches a private page
before the child does, it's the parent which gets a new page.  The
supposed shared mmap of the parent now points to the child's page, not
the parent's.  COW basically just can't do the right thing if a page
is both shared and private at the same time.

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: Hopefully a simple question on /proc/pid/mem

[Eric W. Biederman]

"Stephen C. Tweedie" <sct@redhat.com> writes:

> Hi,
> 
> On Mon, Apr 30, 2001 at 07:13:53PM -0600, Eric W. Biederman wrote:
> 
> > > Hint: think about what happens if you make a shared mapping of a
> > > private proc/*/mem region... 
> > 
> > Now that we have reusable swap cache pages we could make it work
> > correctly, except for the case of the first write a private mapping of
> > file.    Not that we would want to...
> 
> Think about fork.  If a parent forks and then touches a private page
> before the child does, it's the parent which gets a new page.  The
> supposed shared mmap of the parent now points to the child's page, not
> the parent's.  COW basically just can't do the right thing if a page
> is both shared and private at the same time.

Right.  This is a different context but it has the same properties of
what I was thinking of.  The fact that fork has the problem too,
means it's definitely not doable right now.  At least not with the
intuitive semantics.  If we either denied shared mappings of private
mappings or simply promoted them to shared mappings we could easily do a
non-buggy implementation. 

The problem isn't really COW, the copy on write is easy.  The hard
part it to appropriately share the resulting copy.  If we really had
to do this it might be possible by playing with the open method in the
vma_operations.  Implementation wise I think a shared private mapping
of a file is really a harder case than fork COW pages.

I think it is a better argument that since nothing except a mmap of
/proc/pid/mem needs the complexity of simultaneously shared and
private mappings, it isn't worth supporting them.

Eric

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: Hopefully a simple question on /proc/pid/mem

[Richard F Weber]

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

Well ptrace connects, but getting the data out is what seems to be the 
really tough part.  I've seen some examples of opening up the 
/proc/pid/mem file just using the

.................
int addr=0x<some memory address>;
char buffer[255];

proc_file=open ("/proc/pid/mem",O_RDONLY);
lseek(proc_file,addr,SEEK_SET);
read (proc_file,buffer,sizeof(buffer));
.................

But then the system complains about "No Such Process".  I know the 
process is working and this fails as both the user running the target 
process, as well as root.  I'm also using a 2.2.16 kernel stock from 
RH7.0 (but I didn't think that would really matter). I don't need 
register access (at least not yet).

The only other thing I'm wondering is if there is some permission that 
must be granted by the target process, but I've already tried the 
ptrace(PTRACE_TRACEME) line.

Thanks.

--Rich

Stephen C. Tweedie wrote:

>Hi,
>
>On Mon, Apr 30, 2001 at 02:17:13PM -0400, Richard F Weber wrote:
>
>>Hopefully this is a simple question.  I'm trying to work on an external 
>>debugger that can bind to an external process, and open up memory 
>>locations on the heap to allow reading of data.
>>
>>Now I've tried using ptrace(), mmap() & lseek/read all with no success.  
>>The closest I've been able to get is to use ptrace() to do an attach to 
>>the target process, but couldn't read much of anything from it.
>>
>
>ptrace is what other debuggers use.  It really ought to work.
>
>Cheers,
> Stephen
>--
>To unsubscribe, send a message with 'unsubscribe linux-mm' in
>the body to majordomo@kvack.org.  For more info on Linux MM,
>see: http://www.linux.eu.org/Linux-MM/
>


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