Re: [PATCH 03/10] ptrace: implement PTRACE_SEIZE

From: Denys Vlasenko
Date: Thu May 19 2011 - 21:44:52 EST


On Friday 20 May 2011 01:00, Pedro Alves wrote:
> On Thursday 19 May 2011 23:42:12, Denys Vlasenko wrote:
> > On Thursday 19 May 2011 21:31, Pedro Alves wrote:
> > > On Thursday 19 May 2011 15:17:28, Tejun Heo wrote:
> > > > But making SEIZE not trigger INTERRUPT and SETOPTIONS without
> > > > requiring TRACED don't seem too difficult. Jan, would that be enough?
> > > > Oleg, what do you think?
> > >
> > > UUIC, that opens a race where between SEIZEing and
> > > SETOPTIONS(O_TRACE FORK|VFORK|EXEC...), the tracee can
> > > fork/vfork/clone/exec, without the tracer getting the
> > > nice corresponding PTRACE_EVENT_ events.
> >
> > SEIZE,fork-in-tracee,INTERRUPT sequence is indistinguishable
> > from SEIZE happening two microseconds later:
> >
> > fork-in-tracee,SEIZE,INTERRUPT
>
> SEIZE,execvd,INTERRUPT (SETOPTS on interrupt)
>
> will make the tracer see a SIGTRAP that
>
> execvd,SEIZE,INTERRUPT
>
> nor
>
> SEIZE,SETOPTS,execvd (SETOPTS on interrupt)
>
> would cause, isn't it?

Yes, you are right about this particular case.

Execve's extra SIGTRAP is a particularly painful misfeature.


> Now, if it were possible for the tracer to set the
> default OPTS _before_ PTRACE_ATTACH/PTRACE_SEIZE...

I propose to do it *during* SEIZE then. Say, by passing SETOPTION style
option flags in data argument. To fight above example, we'd want
to pass PTRACE_O_TRACEEXEC.

Tejun, what do you think?


> > > In GDBs case, GDB will want to poke at memory
> > > right after attaching
> >
> > ...where "right after attaching" is defined as "when the first ptrace-stop
> > is reported". Which will happen very soon.
>
> Hmm? Why would it happen very soon?
> Isn't the point of SEIZE not
> interrupting that you'd not get any INTERRUPT or stop at all?
> Where is the ptrace-stop coming from?

>From PTRACE_INTERRUPT. Without it, tracee is running. Ptrace API never
allowed poking of running tracees. You need to stop it first.

--
vda
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/