linux-kernel - Re: [patch V2 2/7] futex: Hash private futexes per process

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:	Fri, 27 May 2016 19:10:01 +0200
From:	Sebastian Andrzej Siewior <sebastian@...akpoint.cc>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Darren Hart <darren@...art.com>,
	Ingo Molnar <mingo@...nel.org>,
	Michael Kerrisk <mtk.manpages@...glemail.com>,
	Davidlohr Bueso <dave@...olabs.net>, Chris Mason <clm@...com>,
	Carlos O'Donell <carlos@...hat.com>,
	Torvald Riegel <triegel@...hat.com>,
	Eric Dumazet <edumazet@...gle.com>
Subject: Re: [patch V2 2/7] futex: Hash private futexes per process

On 2016-05-19 14:24:06 [+0200], Peter Zijlstra wrote:
> On Thu, May 05, 2016 at 08:44:04PM -0000, Thomas Gleixner wrote:
> > +static struct futex_hash_bucket *hash_futex(union futex_key *key)
> > +{
> > +#ifdef CONFIG_FUTEX_PRIVATE_HASH
> > +	struct mm_struct *mm = current->mm;
> > +	unsigned int slot;
> > +
> > +	/*
> > +	 * Futexes which use the per process hash have the lower bits cleared
> > +	 */
> > +	if (key->both.offset & (FUT_OFF_INODE | FUT_OFF_MMSHARED))
> > +		return hash_global_futex(key);
> > +
> > +	slot = hash_long(key->private.address, mm->futex_hash.hash_bits);
> > +	return &mm->futex_hash.hash[slot];
> 
> Do we want the option to WARN if we get collisions in this per-process
> hash?
> 
> Because afaiu there is no guarantee what so ever this doesn't happen,
> and collisions here can create the very same priority inversions as are
> possible in the global hash.
> 
> Less likely etc.. more contained since its only the threads of the one
> process that get tangled up, but still possible.

Since the collision is contained the same process it is less dramatic.
But how do you want to warn the user? A trace-event would be handy to
dump the uaddr and slot. The user would have to check the trace and
figure out which slot was assigend to different uaddr. But due to ASLR
the same application might result in a different behaviour on each run.
However, it might be good for a indication about the size of the private
hash…

Sebastian