linux-kernel - Re: [PATCH 06/11] ptrace: make group stop state visible via 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: <20110510165545.GA30198@redhat.com>
Date:	Tue, 10 May 2011 18:55:45 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	jan.kratochvil@...hat.com, vda.linux@...glemail.com,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, indan@....nu,
	Tony Luck <tony.luck@...el.com>,
	Fenghua Yu <fenghua.yu@...el.com>,
	Ralf Baechle <ralf@...ux-mips.org>,
	Kyle McMartin <kyle@...artin.ca>, Helge Deller <deller@....de>,
	"James E.J. Bottomley" <jejb@...isc-linux.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Paul Mackerras <paulus@...ba.org>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Heiko Carstens <heiko.carstens@...ibm.com>,
	"David S. Miller" <davem@...emloft.net>,
	Chris Metcalf <cmetcalf@...era.com>, x86@...nel.org
Subject: Re: [PATCH 06/11] ptrace: make group stop state visible via
	PTRACE_GETSIGINFO

On 05/08, Tejun Heo wrote:
>
> Ptracer can detect tracee entering group stop by watching for the
> group stop trap; however, there is no reliable way to find out when
> group stop ends - SIGCONT may be processed by another thread and
> signal delivery is blocked while tracee is trapped.

Confused.

> This patch adds siginfo.si_pt_flags and uses PTRACE_SI_STOPPED flag to
> indicate whether group stop is in effect or not.  While tracee is
> trapped for anything other than signal delivery and group stop itself,
> tracer can use PTRACE_GETSIGINFO to access this information.  Note
> that it's only available if tracee was seized.

IOW, if the tracee reports via ptrace_notify*, the tracee can look at
si_pt_flags == stop-in-effect. If the tracer reports a signal, the
tracer obviously lacks this info, hmm.

Probably I need more time to get used to this... But at first glance
this looks a bit unnatural. Say, can't we simply implement
PTRACE_GET_GROUP_STOP_STATUS request which returns this (and probably
more) info?

> Later patches will deal with
> notification and trap transition.

OK, probably I'll understand the intent later.

> __SI_TRAP is defined to implement copying of
> the new field to userland.

Heh. I am shy to admit, I didn't know copy_siginfo_to_user() trims
si_code, that is why your change is correct but I spent a lot of time
before I was able to understand this.

>   int main(int argc, char **argv)
>   {
> 	  pid_t tracee, tracer;
> 	  int i;
>
> 	  tracee = fork();
> 	  if (!tracee)
> 		  while (1)
> 			  nanosleep(&ts1s, NULL);
>
> 	  tracer = fork();
> 	  if (!tracer) {
> 		  int last_stopped = 0, stopped;
> 		  siginfo_t si;
>
> 		  ptrace(PTRACE_SEIZE, tracee, NULL,
> 			 (void *)(unsigned long)PTRACE_SEIZE_DEVEL);
> 	  repeat:
> 		  waitid(P_PID, tracee, NULL, WSTOPPED);
>
> 		  if (!ptrace(PTRACE_GETSIGINFO, tracee, NULL, &si)) {
> 			  if (si.si_code) {
> 				  stopped = !!si.si_status;

In this case this "si_code != 0" check is correct, but how can the
tracer detect this case in general?

> @@ -540,6 +542,17 @@ static int ptrace_getsiginfo(struct task_struct *child, siginfo_t *info)
>
>  	error = 0;
>  	*info = *child->last_siginfo;
> +
> +	/*
> +	 * If reporting ptrace trap for a seized tracee, enable reporting
> +	 * of info->si_pt_flags.
> +	 */
> +	if ((child->ptrace & PT_SEIZED) &&
> +	    (info->si_code & (0x7f | ~0xffff)) == (__SI_TRAP | SIGTRAP)) {

Can't we simply check (from->si_code & __SI_MASK) == __SI_TRAP ?

> +		/* report whether group stop is in effect w/ SI_STOPPED */
> +		if (sig->group_stop_count || (sig->flags & SIGNAL_STOP_STOPPED))

We have more and more "group_stop_count || SIGNAL_STOP_STOPPED" checks,
perhaps we should make a helper. Or at least invent the short name to
denote the group-stopped-or-in-progress to simplify the discussions ;)


Still, this is strange. With this change ptrace_getsiginfo() reports
the extra "volatile" info which wasn't reported by the tracee itself.
If the tracer does PTRACE_SETSIGINFO twice in a row, it can see the
different si_pt_flags's.

Oleg.

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