linux-kernel - Re: [Security] [patch] random: make get_random

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 16 May 2009 15:58:28 +0200
From:	Willy Tarreau <w@....eu>
To:	Ingo Molnar <mingo@...e.hu>
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

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

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