Date:	Sat, 16 May 2009 12:39:09 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Willy Tarreau <w@....eu>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	security@...nel.org, Linux@...a.kernel.org, stable@...nel.org,
	Cox <alan@...rguk.ukuu.org.uk>, Arjan@...a.kernel.org,
	List <linux-kernel@...r.kernel.org>, Alan@...a.kernel.org,
	Eric Paris <eparis@...hat.com>, Jake Edge <jake@....net>,
	linux-security-module@...r.kernel.org, mingo@...hat.com,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Matt Mackall <mpm@...enic.com>, Dave Jones <davej@...hat.com>,
	James Morris <jmorris@...ei.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Roland McGrath <roland@...hat.com>,
	de Ven <arjan@...radead.org>
Subject: Re: [Security] [patch] random: make get_random_int() more random


* Willy Tarreau <w@....eu> wrote:

> On Fri, May 15, 2009 at 03:47:17PM +0200, Ingo Molnar wrote:
> > 
> > * Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> > 
> > > On Thu, 14 May 2009, Jake Edge wrote:
> > > >
> > > > It seems like this should be queued up for stable, yes?  I 
> > > > just saw the 2.6.29.4 review patches go out, but this wasn't 
> > > > part of it ...
> > > 
> > > Well, I was hoping to maybe have actual timing numbers from 
> > > some better hash, in case Matt can make one that is efficient 
> > > enough. So I committed the randomness improvement as a clear 
> > > _improvement_ over what we had, but it may not be the final 
> > > version.
> > 
> > yep, it was just a quick hack really. If someone can do a 
> > stronger hash that also happens to be faster i guess we all will 
> > be happy campers. The performance figures showed room for 
> > improvement - how well are those hashes optimized? Many 
> > thousands of cycles ... is that really justified?
> 
> In fact we must keep in mind that those hashes produce far more 
> data than we need and we're throwing that data to the bin on every 
> call. If we use SHA1, we get 160 bits. We should save them and 
> return them by 5 packets of 32 bits, then only call SHA1 once 
> every 5 calls. That way, we get one slower exec every 5 calls but 
> faster calls on average.

Good idea ...

> And if we can't get a good hash to be fast enough, let's make this 
> configurable. Most of us won't ever care about the strength of the 
> hash. People concerned about security won't care about the slower 
> hash. If we set the slower hash by default and have a tunable for 
> it, everyone will have the solution that fits them.

Bad idea IMHO ...

It is a bad idea because such sort of tunables do not really help 
the user as those who tweak are a distinct minority.

Also, having a two-way hack _hinders_ your good idea from being 
adopted for example. Why bother with a faster hash and with using 
the resulting bits sparingly if we can get an 'easy' tunable in and 
can have two sub-par solutions instead of one (harder to implement) 
good solution?

So tunables are really counter-productive - and this is a pet peeve 
of mine.

Every time we have such a tunable for something fundamental we've 
not improved the kernel, we've documented a _failure_ in kernel 
design and implementation.

Sure, we do use tunables for physical constants, limits and other 
natural parameters - and _sometimes_ we just grudingly admit defeat 
and admit that something is really impossible to implement. IMHO 
here we are not at that point yet, at all.

	Ingo
--
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