lkml.org 
[lkml]   [2009]   [May]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2009-05-16 12:45    [W:0.104 / U:0.400 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site