lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 3 Sep 2012 18:05:38 +0200
From:	Oleg Nesterov <>
To:	Al Viro <>
Cc:	Linus Torvalds <>,
	Roland McGrath <>,
Subject: Re: [RFC] semantics of singlestepping vs. tracer exiting

On 09/03, Al Viro wrote:
> 	When tracer exits, everything that had been ptraced by it
> gets its ->ptrace reset to 0 and woken up to run.  Fine, but...
> what should happen if the last thing that had been done to the

Yes. If the tracer exits "unexpectedly", it can leave the tracee in
the inconsistent state.

IIRC, we already discussed this, but I can't recall the result.

> Is that a bug or deliberate
> behaviour?

This is not easy to fix. ptrace_disable() and user_disable_single_step()
is arch dependant, but at least on x86 it assumes that the tracee is not
running, so exit_ptrace() can't do this.

And (iirc) it can even sleep, but this is fixable. We can change
exit_ptrace() to drop/re-acquire tasklist.

And this also complicates PTRACE_DETACH_ASYNC which (imho) we need.
Currently the tracer can't detach the running tracee. And worse, it
can't detach a zombie. It should do wait() but if this process has
alive sub-threads it can do nothing.

This is another reason to move enable/disable step into ptrace_stop().
And in fact I had the patches a loong ago, but we need to cleanup
the usage of PT_SINGLESTEP/PT_BLOCKSTEP first. The tracer should
simply set/clear these PT_ flags and resume the tracee which should
check them and do user_*_single_step() in response.

But. Whatever we do, exit_ptrace() can race with SIGTRAP anyway.

> 	Related question: should execve(2) clear (ptrace-inflicted)
> singlestepping?

Perhaps, but

> Tracer
> exit(), however, does *not* do that right now, so the state after
> execve(2) is theoretically observable.

... why execve() is special?


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

Powered by blists - more mailing lists