linux-kernel - Re: [RFC] Proposal for ptrace improvements

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: <830cc1666bd4a610d5e870218f06bd2d.squirrel@webmail.greenhost.nl>
Date:	Wed, 2 Mar 2011 06:07:35 +0100 (CET)
From:	"Indan Zupancic" <indan@....nu>
To:	"Tejun Heo" <tj@...nel.org>
Cc:	"Denys Vlasenko" <vda.linux@...glemail.com>,
	"Oleg Nesterov" <oleg@...hat.com>,
	"Roland McGrath" <roland@...hat.com>, jan.kratochvil@...hat.com,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org
Subject: Re: [RFC] Proposal for ptrace improvements

Hello,

On Tue, March 1, 2011 19:34, Tejun Heo wrote:
> Maybe it should, maybe not, but that's mostly irrelevant because the
> described behavior is the current behavior.  There is no
> continue-if-not-job-control-stopped operation and we shouldn't change
> that beneath gdb because otherwise not only the behavior changes
> unexpectedly but also the user doesn't have a way to resume the tracee
> from within gdb.  The user has to go to another terminal and send
> SIGCONT explicitly.  If gdb wants to improve the behavior, it sure can
> implement proper job control behavior using the proposed changes.

I'm not sure what Denys is talking about: Currently it's impossible to
pass along SIGSTOP to traced processes. Quoting the ptrace manpage:

   PTRACE_CONT
          Restarts  the stopped child process.  If data is nonzero and not
          SIGSTOP, it is interpreted as a signal to be  delivered  to  the
          child;  otherwise,  no  signal is delivered.

So you can pass along signals, but it's ignored if it happens to be
SIGSTOP. If you emulate SIGSTOP signals in the tracer by not calling
PTRACE_CONT, SIGCONT on the task won't work because the task can't
receive the signal until it's continued by the tracer, but the tracer
doesn't get a new notification until it resumes the task.

As for distinguishing STOP signals from stopped childs: Just don't set
the WUNTRACED flag in the tracer for waitpid.

If you want SIGSTOP to work on a traced task, then you have to add a
new PTRACE_SETOPTIONS option which enables the changed behaviour.
E.g. PTRACE_O_SIGSTOP which does pass all signals, even SIGSTOP for
PTRACE_CONT/SYSCALL/etc. Without something like this I don't see how
you can make job control for traced tasks work.

To me it seems clear that job ctl state should be managed independently
of ptrace stopped state.  I'm not sure how that fits in with your
proposed changes, but my impression is that you make everything a lot
simpler by separating traced stopping/continuing from SIGSTOP/SIGCONT
job control. It's just not the same. A task stopped by a trace event
shouldn't generate a STOP signal for it's parent, only for real SIGSTOPS.

Greetings,

Indan

--
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/