linux-kernel - Re: [PATCH 1/1] ptrace: make sure do_wait() won't hang after 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: <20110214171847.GA14528@redhat.com>
Date:	Mon, 14 Feb 2011 18:18:47 +0100
From:	Oleg Nesterov <oleg@...hat.com>
To:	Denys Vlasenko <vda.linux@...glemail.com>
Cc:	Tejun Heo <tj@...nel.org>, Roland McGrath <roland@...hat.com>,
	jan.kratochvil@...hat.com, linux-kernel@...r.kernel.org,
	torvalds@...ux-foundation.org, akpm@...ux-foundation.org
Subject: Re: [PATCH 1/1] ptrace: make sure do_wait() won't hang after
	PTRACE_ATTACH

On 02/14, Denys Vlasenko wrote:
>
> On Mon, Feb 14, 2011 at 4:06 PM, Oleg Nesterov <oleg@...hat.com> wrote:
> > On 02/13, Denys Vlasenko wrote:
> >>
> >> For example, PTRACE_DETACH requires tracee to be stopped to succeed.
> >> If debugger tries to detach while the tracee is running, it will get
> >> an error. This forces debugger to do stupid things like sending SIGSTOP,
> >> then waiting for tracee to stop, then doing PTRACE_DETACH, then
> >> sending SIGCONT. Of course, while this dance is performed,
> >> any SIGSTOPs/SIGCONTs which may be  sent to the tracee by other processes
> >> are totally disrupted by this.
> >
> > Yes.
> >
> >> The natural (for me) fix is to make PTRACE_DETACH work even on running
> >> tracee. It simply makes a lot of sense. Why on earth do we need tracee
> >> to be stopped? There is no reason.
> >
> > Agreed, but
> >
> >> But this is a change in ptrace behavior, and therefore is not acceptable
> >> for Roland.
> >
> > I agree with Roland. Not only this is too visible change, it is not clear
> > what detach-with-signal can do if the tracee is not stopped.
> >
> > This was (very briefly) discussed recently. Probably we can implement
> > PTRACE_DETACH_RUNNING (the name is random) which doesn't require the
> > stopped tracee but ignores the "data" argument.
>
> IIRC data argument is already ignored by PTRACE_CONT if it is issued in
> the ptrace stop which wasn't caused by signal delivery to the tracee.

Yes, almost correct. There are a couple of exceptions like syscall entry.

> So, it isn't a new precedent to make
> ptrace(PTRACE_DETACH, ...,  <something>);
> to ignore <something> if tracee isn't in signal-delivery-induced ptrace stop.
> In particular, if it isn't in any stop at all, if it's running.

Yes, agreed, but still the new option looks safer to me.

Suppose that debugger sends SIGFOO to the tracee and then it does
ptrace(PTRACE_DETACH, SIGBAR). If it forgets to do wait() in between
it should see the error.

Perhaps this doesn't matter, but compatibility is always good unless
we have to break things. And we should change strace anyway to detach
without SIGSTOP/etc, it can use the new option.

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/