linux-kernel - Re: [PATCH] Fix a race in pid generation that causes pids to be reused immediately.

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:	Tue, 15 Jun 2010 17:25:40 +1000
From:	Paul Mackerras <paulus@...ba.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	tytso@....edu, Salman <sqazi@...gle.com>, mingo@...e.hu,
	linux-kernel@...r.kernel.org, peterz@...radead.org,
	tytso@...gle.com, torvalds@...ux-foundation.org, walken@...gle.com,
	Chen Liqin <liqin.chen@...plusct.com>,
	Lennox Wu <lennox.wu@...il.com>
Subject: Re: [PATCH] Fix a race in pid generation that causes pids to be
 reused immediately.

On Mon, Jun 14, 2010 at 09:21:50PM -0700, Andrew Morton wrote:

> If that happens then the best fix is for those architectures to get
> themselves a cmpxchg64().  Unless for some reason it's simply
> unimplementable?  Worst case I guess one could use a global spinlock. 
> Second-worst-case: hashed spinlocks.

Spinlocks won't help as long as you can use cmpxchg64 on any old u64
that is also accessed directly.  UP can disable interrupts, of course,
but for SMP we would have to restrict cmpxchg64 to some type
(atomic64_t, maybe) for which you have to use an accessor function to
read it, so we can take the spinlock around the reads.

I suspect it isn't worth the trouble.  Note that I'm talking
specifically about cmpxchg64 here, not cmpxchg.

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