Re: [PATCH] 2-ptrace_multi

[renzo@cs.unibo.it (Renzo Davoli)]

On Fri, May 19, 2006 at 09:09:52AM -0400, Daniel Jacobowitz wrote:
> On Fri, May 19, 2006 at 11:07:26AM +0200, Renzo Davoli wrote:
> > On Thu, May 18, 2006 at 07:23:13PM -0700, Ulrich Drepper wrote:
> > > On 5/18/06, Renzo Davoli <renzo@cs.unibo.it> wrote:
> > > >e.g. To virtualize a write you'd have to call PTRACE_PEEKDATA for each
> > > >word of the buffer, very many hundreds cycles lost.
> > > 
> > > No, this is not how programs should do it.  Just open /proc/PID/mem
> > > and use pread() with an offset corresponding to the address.  Now,
> > > repeat your timings using this technique.
> > 
> > That would be faster to access the memory but:
> > - the manager has to keep one open file per controlled process
> 
> No, it doesn't.  It can open it as needed.  It can even maintain a
> cache of open mem files.
> 
> GDB's been opening it as needed for years.  It works very well and is
> drastically faster than PTRACE_PEEKDATA.
> 
Over all I could speed up just half of the calls because I cannot write
in /proc/<pid>/mem !
You are proposing a solution which speeds up writes but not reads.

(from fs/proc/base.c)
#define mem_write NULL

#ifndef mem_write
/* This is a security hazard */
static ssize_t mem_write(struct file * file, const char * buf,
       size_t count, loff_t *ppos)
....
#endif

My proposals should not add any threats which is not already in 
PTRACE_POKEDATA. Now, either the threat do currently exist and my
proposed patch makes is exploitable in a faster way, or it did not
exist and it still does not exist.
PTRACE_MULTI just executes several ptrace requests in a single call.

Other projects would benefit from a similar patch:
see: www.cs.wisc.edu/condor/doc/parrot-agm2003.pdf 
http://www.cse.nd.edu/~dthain/papers/ibox-sc05.pdf
They had the very same problem.

	renzo