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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 11 May 2011 10:08:52 +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,
	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

Hello,

On Tue, May 10, 2011 at 06:55:45PM +0200, Oleg Nesterov wrote:
> 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.

Which indicates tracee is in group stop trap.

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

I don't know.  PTRACE_GETSIGINFO seemed to already fit the bill and I
want to avoid introducing a new request if at all possible.  It sure
is a bit quirky but doesn't compromisea functionality.

> > __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.

Oh, don't be shy.  I scratched my head for quite a while trying to
figure out why the hell the new flag field isn't getting out to
userland.  It's an ugly piece of sh*t.  :-)

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

This was quick hack.  Proper test would look like,

	si.si_code && (si.si_pt_flags & PTRACE_SI_STOPPED)

> > @@ -540,6 +542,17 @@ static int ptrace_getsiginfo(struct task_struct *child, siginfo_t *info)
> > +	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 ?

Right, I originally lifted the test from ptrace_notify() before adding
__SI_TRAP and forgot to update it later.  Will change.

> > +		/* 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 ;)

Yeah, how about group_stop_in_effect()?

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

(answering to both get/setsiginfo concerns)

* I think we better block PTRACE_SETSIGINFO for non signal delivery
  traps.  It doesn't make any sense.  Let's just fail that with
  -EINVAL if PT_SEIZED.

* I don't think PTRACE_GETSIGINFO returning volatile information to be
  problematic.  The information is generated on the fly on trap
  anyway.  For non signal delivery traps, PTRACE_GETSIGINFO is
  basically (ab)using siginfo as a container for debugging
  information.  It might have been better if something else was used
  from the beginning but the damage is already done and I don't see
  too much benefit in making things pretty at this point.

Thank you.

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