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]

Message-ID: <20110515162630.GG23665@htj.dyndns.org>
Date:	Sun, 15 May 2011 18:26:30 +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, Jan.

On Sun, May 15, 2011 at 05:56:02PM +0200, Jan Kratochvil wrote:
> It was already addressed by me before so I will give more reasons:
> 	https://lkml.org/lkml/2011/3/1/309

Hmmm... I don't think the argument given in the message is valid.  The
new trap doesn't have any side effect (other than possible syscall
restart (or -EINTR failure) and performance overhead) so there
wouldn't be any problem from correctness POV and the code to SEIZE and
establish initial state would be simple.

> GDB already has mode `set observer on' (in this case we are interested in its
> part `set may-interrupt off') - see: $ info '(gdb)Observer Mode'
> 	# If you want to [...] observe program behavior without any chance of
> 	# disruption by GDB
> This is an increasingly requested feature as one of the ways of monitoring.

Hmmm... transparency.  Other than signal_wakeup (syscall restart /
-EINTR), there is no side effect of SEIZE - from transparency POV,
this should be considered fully transparent.  signal_wakeup can happen
anytime even without signals.  It's an integral part of the
programming interface.  I don't know.  Maybe.

> There are also requests to handle applications using 10000+ threads, which
> currently have problems with GDB.  One can imagine a needless
> waitpid+PTRACE_CONT is not a help.

Yeap, performance could be a legitimate concern but then again I'm not
sure here either - the whole thing is quite slow and not trapping on
SEIZE might not amount to all that much.  Again, maybe.

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.

> > Which trap will happen isn't fixed.  If other trap conditions exist (signal
> > delivery or group stop), they might be taken; otherwise, a trap with
> > exit_code SIGTRAP | (PTRACE_EVENT_INTERRUPT << 8) is taken.
> 
> What if PTRACE_INTERRUPT is called by tracer only after the tracee has stopped
> on a signal delivery?  It should be ignored in such case - as the first signal
> will not be PTRACE_EVENT_INTERRUPT.  (Sorry if you have stated it somewhere.)

I think you're somewhat confused here.  Well, ptrace manpage is pretty
confused too.  Those are different traps.  You can tell them apart
from userland and it doesn't matter which order or how many times
INTERRUPT occurs.

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/