From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757183AbZEPOA0 (ORCPT ); Sat, 16 May 2009 10:00:26 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755114AbZEPOAK (ORCPT ); Sat, 16 May 2009 10:00:10 -0400 Received: from mx-out2.daemonmail.net ([216.104.160.39]:52431 "EHLO mx-out2.daemonmail.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752953AbZEPOAJ (ORCPT ); Sat, 16 May 2009 10:00:09 -0400 From: "Michael S. Zick" Reply-To: lkml@morethan.org To: "Eric W. Biederman" Subject: Re: [Security] [patch] random: make get_random_int() more random Date: Sat, 16 May 2009 09:00:00 -0500 User-Agent: KMail/1.9.9 Cc: Ingo Molnar , Willy Tarreau , Linus Torvalds , security@kernel.org, Linux@hera.kernel.org, stable@kernel.org, Cox , Arjan@hera.kernel.org, List , Alan@hera.kernel.org, Eric Paris , Jake Edge , linux-security-module@vger.kernel.org, mingo@redhat.com, Matt Mackall , Dave Jones , James Morris , Andrew Morton , Roland McGrath , de Ven References: <20090505195246.GC21973@elte.hu> <20090516103909.GB6261@elte.hu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905160900.04380.lkml@morethan.org> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat May 16 2009, Eric W. Biederman wrote: > Ingo Molnar writes: > > > * Willy Tarreau 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@vger.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