Messages in this thread | | | Date | Sat, 16 May 2009 12:39:09 +0200 | From | Ingo Molnar <> | Subject | Re: [Security] [patch] random: make get_random_int() more random |
| |
* Willy Tarreau <w@1wt.eu> wrote:
> On Fri, May 15, 2009 at 03:47:17PM +0200, Ingo Molnar wrote: > > > > * Linus Torvalds <torvalds@linux-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
| |