Re: [PATCH] 2-ptrace_multi

From: Renzo Davoli
Date: Fri May 19 2006 - 13:44:59 EST

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@xxxxxxxxxxx> 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)

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:
They had the very same problem.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at