lists.openwall.net   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 <oleg@...hat.com>
To:	Al Viro <viro@...IV.linux.org.uk>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Roland McGrath <roland@...hat.com>,
	linux-kernel@...r.kernel.org
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
> child was PTRACE_SINGLESTEP?

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?

Olef.

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

Powered by blists - more mailing lists