linux-kernel - Re: [PATCHSET ptrace] ptrace: implement PTRACE_SEIZE/INTERRUPT and group stop notification

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: <20110509094839.GG1661@htj.dyndns.org>
Date:	Mon, 9 May 2011 11:48:39 +0200
From:	Tejun Heo <tj@...nel.org>
To:	Denys Vlasenko <vda.linux@...glemail.com>
Cc:	oleg@...hat.com, jan.kratochvil@...hat.com,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, indan@....nu
Subject: Re: [PATCHSET ptrace] ptrace: implement PTRACE_SEIZE/INTERRUPT and
 group stop notification

Hello,

On Mon, May 09, 2011 at 12:27:41AM +0200, Denys Vlasenko wrote:
> > After PTRACE_SEIZE, tracee will trap.
> 
> So which is it? Does PTRACE_SEIZE trap or not?

PTRACE_SEIZE attaches to a new tracee and traps it.  INTERRUPT traps
already attached tracee.

> > * Group stop notification is implemented as sticky INTERRUPT trap
> >   which gets cleared on PTRACE_GETSIGINFO and notifies both start and
> >   end of group stops.
> > ...
> > * The trap condition is sticky until GETSIGINFO.  This is necessary
> >   because generation of the event may race with CONT and ptracer may
> >   miss the trap.
> 
> As a userspace guy, I find this explanation unclear.
> 
> What is "sticky" exactly? siginfo.si_pt_flags contents?
> 
> What exactly "sticky" means? If PTRACE_GETSIGINFO is not queried
> by userspace after it observed ptrace stop, what will happen?

It means that INTERRUPT trap will happen repeatedly until the
condition is cleared by PTRACE_GETSIGINFO.

> Real world users of ptrace, such as strace, will likely avoid
> PTRACE_GETSIGINFO'ing on every stop - they will examine wait status,
> and query PTRACE_GETSIGINFO only if they know they have to -
> such as when they see a job stop signal (SIGSTOP/SIGTSTP/etc),
> not SIGTRAP.
>
> Is it still possible, or PTRACE_GETSIGINFO will be a mandatory call
> after each ptrace stop for any userspace usage which wants to track
> job stop status of the tracee?

You can tell INTERRUPT trap from the exit_code stored in si_status
(si_code CLD_TRAPPED and si_status SIGTRAP | (PTRACE_EVENT_INTERRUPT
<< 8)), so you can call GETSIGINFO only after INTERRUPT traps, which
should be enough for job control notifications, but you would also
have to do GETSIGINFO to discern signal delivery and actual group stop
traps (si_code zero and si_status is the signo for both).

> I don't know the status of ptrace test suite after I stopped working
> on strace (did the suite bit rot, or is it maintained and still
> relevant?). If it is still in use, I can adapt these tests and add
> them to it.

I have no idea but am planning write more complete example program.
The ones included in the commit messages are mostly just to show that
the basic functionality implemented by the commit works, so they
aren't necessarily good examples.

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/