Messages in this thread | | | Date | Sat, 16 May 2009 15:58:28 +0200 | From | Willy Tarreau <> | Subject | Re: [Security] [patch] random: make get_random_int() more random |
| |
On Sat, May 16, 2009 at 12:39:09PM +0200, Ingo Molnar wrote: > > 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.
I don't agree with your point. It is good when the user must choose between performance and security. For instance, if we had to choose between a very slow but secure TCP stack and a very fast but less secure one, instead of making it half way for everyone, I'd prefer to be able to select my usage. You see this in Solaris with their tcp_strong_iss tunable (which provides more values than needed, as people only use either 0 (fast) or 2 (secure)).
As long as we're not forced to choose between the two possibilities, we don't need a tunable, but if we are forced to slow down exec by 20%, surely there are people who would prefer to ignore the security aspect and keep their original performance.
Willy
| |