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]

Date:	Wed, 2 Mar 2011 15:43:22 +0100
From:	Tejun Heo <tj@...nel.org>
To:	Denys Vlasenko <vda.linux@...glemail.com>
Cc:	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

Hi,

On Wed, Mar 02, 2011 at 12:48:56PM +0100, Denys Vlasenko wrote:
> > Of course, all ptrace traps are SIGTRAPs.
> 
> Except for those SIGSTOPs in children on auto-attach
> via PTRACE_O_TRACE[V]FORK / PTRACE_O_TRACECLONE options...

Aren't they just using SIGSTOP's to trigger signal delivery path?  The
signal can be delivered, right?  Checking the source code.... Yeah, it
genuinely generates SIGSTOP.

> >> Why not SIGCONT? This event is, after all, caused by SIGCONT.
> >> It would be so much nicer to be able to detect it with single if()
> >> in the debugger...
> >
> > I disagree.  It's a ptrace trap.  It should use SIGTRAP.  We just need
> > well defined siginfo output to distinguish between them.  It's not
> > like we can avoid siginfo anyway.
> 
> Performance problem here. Strace is already suffering from being
> rather slow, especially for multi-threaded processes.
> 
> So far strace was able to avoid querying siginfo on every stop.
> 
> In order to make job control stop work properly, it will now need
> to query siginfo, but only if signo==SIGSTOP. SIGSTOPs don't
> occur too often, definitely not twice per syscall as SIGTRAPs do,
> so it's not a problem.
> 
> With your proposal to show resume-from-job-control-stop-via-SIGCONT
> as SIGTRAP, *every* SIGTRAP stop needs to be followed
> by PTRACE_GETSIGINFO.

I don't think it's a good idea to make these basic design choices
based on optimization concerns like the above.  We're not talking
about read/write(2) here.  If PTRACE_GETSIGINFO really becomes that
much of a performance bottleneck, we can put it in vdso, but I really
doubt it would come to that.

> int main()
> {
>        signal(SIGSTOP, sig);
>        signal(SIGCONT, sig);
>        signal(SIGWINCH, sig);
>        signal(SIGABRT, sig);
>  again:
>        printf("PID: %d\n", getpid());
>        fflush(NULL);
>        errno = 0;
>        sleep(30);
>        int e = errno;
>        printf("after sleep: errno=%d %s\n", e, strerror(e));
>        if (e) goto again;
>        return 0;
> }
> 
> # ./a.out
> PID: 16382
>  <------ kill -STOP 16382
>  <------ kill -ABRT 16382
>  <------ kill -WINCH 16382
>  <------ kill -CONT 16382
> sig: 28 Window changed
> sig: 18 Continued
> sig: 6 Aborted
> after sleep: errno=4 Interrupted system call
> PID: 16382
> 
> 
> Therefore we also need to think about this aspect of SIGCONT behavior
> under debuggers.
> 
> Do we provide for the mechanism for debuggers to
> prevent execution of *SIGCONT userspace handler*?

Yeah, it's not different from any other signal.  Just squash the
signal when ptrace signal delivery trap is taken, which is completely
separate from termination of job control stop triggered by _emission_
of SIGCONT.  The two are separate.  The proposed changes don't affect
the delivery path at all.  I really can't understand what your point
is.

> And, looking at the example above, I see that on resume from stop,
> *SIGCONT userspace handler* actually doesn't run as *the first handler*
> after SIGCONT. Other pending signal's handlers may be executed before it.

Signal delivery is not FIFO.  There are some rules that the code
describes.  If you're interested, take a look at the code but in
general it would be better to avoid assuming fixed order between
signal generations and deliveries.

> How would the above example look under ptraced process? Particularly,
> this sequence:
>  <------ kill -STOP 16382
>  <------ kill -ABRT 16382
>  <------ kill -WINCH 16382
>  <------ kill -CONT 16382
> sig: 28 Window changed
> sig: 18 Continued
> sig: 6 Aborted

There's NO difference regarding signal delivery.  It stays the SAME.

Thanks.

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