linux-kernel - Re: PTRACE_SEIZE should not stop [Re: [PATCH 02/11] ptrace: implement PTRACE

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 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 15 May 2011 19:25:05 +0200
From:	Tejun Heo <tj@...nel.org>
To:	Jan Kratochvil <jan.kratochvil@...hat.com>
Cc:	oleg@...hat.com, vda.linux@...glemail.com,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, indan@....nu
Subject: Re: PTRACE_SEIZE should not stop  [Re: [PATCH 02/11] ptrace:
 implement PTRACE_SEIZE]

Hello,

On Sun, May 15, 2011 at 07:15:12PM +0200, Jan Kratochvil wrote:
> On Sun, 15 May 2011 18:26:30 +0200, Tejun Heo wrote:
> > the code to SEIZE and establish initial state would be simple.
> 
> In normal case yes; but one needs to handle all the corner cases when the
> first signal is not INTERRUPT; which one usually does not handle as during
> development (=in normal cases) it is always INTERRUPT.
> 
> Such thing is even difficult to test in QA testcases as in some cases one just
> cannot reproduce the (in current case) non-SIGSTOP signal arriving as first
> one.

Understood.  AFAICS, there will be two different initial traps
(they're not signals!) which can happen - signal delivery trap and
INTERRUPT (renamed to STOP) trap.  We should be able to exclude signal
delivery trap from happening as the first trap.  Oleg, can you think
of other traps which could happen right after SEIZE?

Maybe this is best solved with a test case which can reliably trigger
different initial traps sites?

> > How long does it take to attach to / detach from 10000+ threads?  If
> > you don't do it serially, it shouldn't take that long.
> 
> It is not (such) a problem it takes time.  It is a problem it stops the tracee
> for a moment which completely changes the tracee's racy behavior one tries to
> debug.

Okay, timing artifacts.  Yes, it is a valid point but I'm still not
sure.  Let's think about it.

> > You can tell them apart from userland and it doesn't matter which order or
> > how many times INTERRUPT occurs.
> 
> I must know in which order they come to know when the tracee is still stopped
> and I collect the signals to be displayed to the user and at which moment
> there are no more signals in the queue and I start waiting on the debuggee
> which started running.
> 
> Otherwise I can workaround it by various waitpid(NOHANG)s but it is better if
> the ordering and when INTERRUPT is / is not reported is well defined.

Hmmm... you should be able to tell that without resorting to WNOHANG
or depending on order of traps.  That's the goal anyway.  I'm a bit
confused tho.  What do you mean by "the tracee is still stopped"?
Tracee is always stopped (or rather trapped) after reporting a trap.

Thanks.

-- 
tejun
--
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/