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: <20130805174712.GA8461@redhat.com>
Date:	Mon, 5 Aug 2013 19:47:12 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Felipe Contreras <felipe.contreras@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 3.11-rc4

On 08/05, Linus Torvalds wrote:
>
> On Mon, Aug 5, 2013 at 6:29 AM, Oleg Nesterov <oleg@...hat.com> wrote:
> >
> > I never used wine, but I am puzzled anyway. This patch really looks
> > like a simple and minor bugfix.
>
> The patch is indeed trivial, but.. What's the locking here?
>
> Afaik, ptrace_detach() by the parent can race with do_exit() by the
> child, and they now _both_ do flush_ptrace_hw_breakpoint().

That would be bad. And that is why exit_ptrace() doesn't do this.

But we rely on ptrace_freeze_traced(). If the child can exit (or
even run), we have other problems which were hopefully fixed by
9899d11f "ensure arch_ptrace/ptrace_request can never race with
SIGKILL"

> We have that whole "get tasklist_lock for writing and then
> check child->ptrace" logic there exactly due to that race, no?

Exactly. But note that this code is very old. We can remove the
"This child can be already killed" logic, and we can do more
simplifications in ptrace paths.

In fact, some recent changes already rely on the fact the tracee
can't go away, say ptrace_peek_siginfo()->spin_lock_irq(siglock)
is not safe without ptrace_freeze_traced().

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ