linux-kernel - Re: [PATCHSET] ptrace,signal: Improve ptrace and job control interaction

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: <20110328085824.GE16530@htj.dyndns.org>
Date:	Mon, 28 Mar 2011 10:58:24 +0200
From:	Tejun Heo <tj@...nel.org>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	jan.kratochvil@...hat.com, vda.linux@...glemail.com,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, indan@....nu, roland@...k.frob.com
Subject: Re: [PATCHSET] ptrace,signal: Improve ptrace and job control
 interaction

Hey,

On Sat, Mar 26, 2011 at 07:25:54PM +0100, Oleg Nesterov wrote:
> > Explicit wake_up_state() without kick_process() is okay there because
> > if the code assumes that the tasks are guaranteed to pass through
> > signal delivery path whenever event worthy of notification happens
> > (either SIGNAL_STOP_STOPPED or group_stop_count is set).  PTRACE_CONT
> > breaks that as the tracee could be running in userland and thus the
> > solution is to add kick_process() as in signal_wake_up().
> >
> > Am I making any sense?
> 
> Perhaps. This depends on how we define/implement the new behaviour.
> 
> It is not clear to me what the new trap should actually do. And how.
> Either way, prepare_signal(SIGCONT) should do something with the
> ptraced threads, and this is what we should care about. Probably
> we can set TIF_SIGPENDING if task_ptrace() is true.
> 
> Anyway we should ensure SIGCONT can't race with detach.

Hmmm... setting TIF_SIGPENDING and kicking the task to enter signal
delivery path doesn't have any side effect when it's running in
userland, which is the problematic case here anyway.  Is there any
reason we should be careful about this?

> > * Before CLD_STOPPED notification for the incomplete-stop/cont
> >   sequence can be made, recalc_sigpending() happens.
> >
> > * CLD_STOPPED notification is pending but TIF_SIGPENDING isn't set and
> >   the task isn't in signal delivery path and can continue execution.
> 
> This doesn't matter, or I misunderstood.
> 
> We only add "SIGNAL_CLD_* | SIGNAL_STOP_CONTINUED" if we know there
> is at least one thread in get_signal_to_deliver()->do_signal_stop()
> paths. In this case we do not rely on TIF_SIGPENDING at all.

We set SIGNAL_CLD_STOPPED if group_stop_count wasn't zero, ie. if
group stop has initiated, which will be delivered as soon as any task
enters signal delivery path.  So, there's a path that we schedule a
notification and doesn't enforce the delivery until something happens
and a task in the group gets called into signal delivery path somehow,
which is wrong.  We need to call them into the delivery path on the
generation of the notification regardless of ptrace.

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/