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

[Denys Vlasenko]

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/