linux-kernel - Re: [PATCH 11/11] ptrace: implement group stop notification for ptracer

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:	Wed, 11 May 2011 11:05:51 +0200
From:	Tejun Heo <tj@...nel.org>
To:	Denys Vlasenko <vda.linux@...glemail.com>
Cc:	oleg@...hat.com, jan.kratochvil@...hat.com,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, indan@....nu
Subject: Re: [PATCH 11/11] ptrace: implement group stop notification for
 ptracer

Hello, Denys.

On Wed, May 11, 2011 at 12:37:34AM +0200, Denys Vlasenko wrote:
> > When group stop state of a seized tracee changes, JOBCTL_TRAP_NOTIFY
> > is set, which triggers INTERRUPT trap but is sticky until the next
> > PTRACE_GETSIGINFO.
> 
> Why INTERRUPT trap? For group stops, we already have perfectly working
> way to detect such a stop.

Debugger may continue tracee and put it in a different trap.  In such
cases, group stop may be initiated and lifted multiple times while a
tracee is trapped.  It's much nicer to have symmetric notifications in
those cases.

Also, we might end up adding more status flags to si_pt_flags and it's
much better to be able to say "INTERRUPT becomes and stays pending
until the next GETSIGINFO if any of these flags may have chagned" than
"if XXX change from x to y, or YYY changes to x to y or y to x,
... blah blah".

> Can we just add a "group cont" notification which looks like
> a waitpid result with WIFCONTINUED(waitpid_status) == 1 to the tracer?

Consider the following scenario.

1. A syscall traced tracee enters group stop while returning from a
   syscall.  Tracer is notified.

2. SIGCONT generated.  Tracee is woken up and wait state is generated.

3. Tracee traps for syscall completion before tracer has chance to
   wait(2).

4. Oops, continued wait state lost.

Note that generation of another trap can't be used to determine end of
group stop.  It might already have been PTRACE_CONT'd.

This happens because wait states don't queue and shows why edge (or
instance) notifications are usually worse than level ones.  Think
about RT signals which are jokes.

> > Re-trapping is used only for group stop and INTERRUPT traps.  If
> > tracer wants to get notified about group stop, it either leaves tracee
> > in the initial group stop trap or puts it into INTERRUPT trap.  When
> > INTERRUPT trap is scheduled while tracee is already in a trap,
> 
> Sane tracer has no need to do PTRACE_INTERRUPT on a tracee
> which is already stopped (for whatever reason): it already knows
> it's stopped, and why. PTRACE_INTERRUPT is useful to cleanly stop
> _running_ tracees.

1. User wants to continue stopped task to investigate.

2. Investigation done, now the user wants to wait for the end of group
   stop which will happen externally.

3. Regardless of the current trap tracee is in, debugger can schedule
   INTERRUPT and be sure that tracee will trap into INTERRUPT without
   returning to userland and that it will be notified of group stop
   state changes.

According to you, the above use case is insane, which might be true
but I don't really care.  I still want to have gdb which knows how to
do the above.

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/