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

Hello, Denys.

On Fri, May 20, 2011 at 12:48:07AM +0200, Denys Vlasenko wrote:
> > Hmm. At least now I understand the meaining what "sticky" means in
> > this discussion ;) I was confused.
> 
> I still don't see why is it needed. Userspace API doesn't require it.
> 
> Are you trying to solve/simplify something on the kernel side with it?

No, no.  Please consider the following scenario.

1. A process has two threads t1 and t2.  t1 is ptraced by p1.  Both t1
   and t2 are running.

2. p1 INTERRUPTs t1.  t1 enters TRAP_STOP and p1 notices it.

3. Something else sends SIGSTOP to t2 which initiates group stop.

4. As t1 re-traps to notify p1 of group stop, p1 issues PTRACE_CONT.

5. PTRACE_CONT succeeds right after t1 re-traps for notification and
   t1 resumes execution.

6. p1 has no way to find out the group stop which is now in effect.

And vice-versa for SIGCONT.  When an event needs to be delivered, the
event should remain pending until the target the event is destined to
has fetched the event; otherwise, the event can be lost.  Here, the
event to be delivered is change of group stop state and fetching
mechanism is GETSIGINFO.  The event should remain pending until
GETSIGINFO is called.

The only requirement is for the ptracer to call PTRACE_GETSIGINFO on
PTRACE_EVENT_STOP's which can be determined from the wait(2) exit
code.  If ptracer does that, there won't be any unnecessary 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/