linux-kernel - RE: Question about clearing of tsk->robust

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] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.00.1102152354070.26192@localhost6.localdomain6>
Date:	Wed, 16 Feb 2011 00:01:24 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	"Kenneth Albanowski (Palm GBU)" <Kenneth.Albanowski@...m.com>
cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <peterz@...radead.org>,
	Jakub Jelinek <jakub@...hat.com>,
	Andreas Schwab <schwab@...ux-m68k.org>
Subject: RE: Question about clearing of tsk->robust_list in clone

On Tue, 15 Feb 2011, Kenneth Albanowski (Palm GBU) wrote:

> On Tue, 15 Feb 2011, Thomas Gleixner wrote:
> 
> > The sanity checks in exit_robust_list will catch that mutex_1
> > owner is not matching, but that makes it not more correct.
> 
> Yes, that's my remaining question: whether the intention was that the
> owner filter would often be preventing erroneous unlocks, or whether
> there should never be an inappropriate list in normal usage. The owner
> check does seem sufficient to prevent mayhem if the list pointer is
> copied to the child.

It's task state, so we cannot keep state around which belongs to some
other task. 

Of course we have nevertheless sanity checks in place as we have no
idea what kind of crap user space hands us as "robust_list" pointer.

Ideally we never need to walk that list at all in the normal exit
case when user space behaves nicely.
 
> On Tue, 15 Feb 2011, Peter Zijlstra wrote:
> 
> > Realistically libpthread should register an on_fork() callback to 
> > ensure the state is properly propagated.
> 
> Agreed, that seems reasonable, with only the minor impact of an
> additional set_robust_list call. That resolves this as a libc issue,
> not a kernel issue.

As I said, I don't understand that argument of the additional call at
all. We do it on every process start and on every pthread_create
already, just fork() was forgotten somehow.

Thanks,

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