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]
Message-ID: <20110515172505.GL23665@htj.dyndns.org>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ