Re: [Security] [patch] random: make get_random_int() more random

[Ingo Molnar]

* Willy Tarreau <w@xxxxxx> wrote:

> On Fri, May 15, 2009 at 03:47:17PM +0200, Ingo Molnar wrote:
> > 
> > * Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/