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: <201105090027.41534.vda.linux@googlemail.com>
Date:	Mon, 9 May 2011 00:27:41 +0200
From:	Denys Vlasenko <vda.linux@...glemail.com>
To:	Tejun Heo <tj@...nel.org>
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

On Sunday 08 May 2011 17:48, Tejun Heo wrote:
> Hello,
> 
> This patchset implements new ptrace requests SEIZE and INTERRUPT and
> also add group stop notification mechanism for ptracer.  Combined,
> this implements "P4. PTRACE_SEIZE" and "P5. ^Z and fg for tracees" of
> the ptrace job control improvements proposal[1].
> 
> Please note that there are some deviations from the proposal.

No battle plan survives contact with the enemy :)

> * As suggested by Oleg, PTRACE_SEIZE only serves as ATTACH without
>   signal/job control side-effects.  After attached, PTRACE_INTERRUPT
>   should be used to trap tracee without side effect.

Hmm, in "[PATCH 02/11] ptrace: implement PTRACE_SEIZE" you are saying:

> After PTRACE_SEIZE, tracee will trap.

So which is it? Does PTRACE_SEIZE trap or not?


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

Your example code in
"[PATCH 11/11] ptrace: implement group stop notification for ptracer"
does this:

                  waitid(P_PID, tracee, NULL, WSTOPPED);

                  if (!ptrace(PTRACE_GETSIGINFO, tracee, NULL, &si)) {
                          if (!si.si_code) {
                                  printf("tracer: SIG %d\n", si.si_signo);
                                  ptrace(PTRACE_CONT, tracee, NULL,
                                         (void *)(unsigned long)si.si_signo);
                                  goto repeat;
                          }
                          stopped = !!si.si_status;
                  } else
                          stopped = 1;

                  if (stopped != last_stopped)
                          printf("tracer: stopped=%d\n", stopped);
                  last_stopped = stopped;

                  if (!stopped)
                          ptrace(PTRACE_CONT, tracee, NULL, NULL);

That is, it always queries PTRACE_GETSIGINFO, which means this example
doesn't demonstrate "stickiness".


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?


> Each patch implementing new feature includes test program showing its
> functionality.  Notification would probably need a bit more polishing
> but all the needed functionalities are there.

This is great! Thanks!

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.

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