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]

Message-Id: <200905160900.04380.lkml@morethan.org>
Date:	Sat, 16 May 2009 09:00:00 -0500
From:	"Michael S. Zick" <lkml@...ethan.org>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Ingo Molnar <mingo@...e.hu>, Willy Tarreau <w@....eu>,
	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,
	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, Eric W. Biederman wrote:
> Ingo Molnar <mingo@...e.hu> writes:
> 
> > * Willy Tarreau <w@....eu> wrote:
> >
> >
> > 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.
> 
> In the lwn comment section there was a suggestion to use a high
> quality stream cipher (AES?) instead of sha1 or the half md4 thing.
> Apparently those should be both stronger and faster.
> 
> I don't know enough about it except to say that sounds right in
> principle.
> 
> Apparently some of the BSDs do something similar with arc4random.
> arc4 is old and in some case broken so it is unlikely to make a good
> choice at this point, but the overall design of a stream cipher
> that is rekeyed ever 5 minutes seems sound.
> 
> Eric
> --
> 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/
> 
> 

And when building for the VIA processors that have the
hardware rng in the padlock firmware - -
Let the kernel use that for a high quality RNG.

Note: This may require a Kbuild tweak to force the via-rng
driver to be built-in if this solution is selected.

PS: I have two (different) VIA C7-M machines available for testing.

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