From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756754AbZEPKK5 (ORCPT ); Sat, 16 May 2009 06:10:57 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755797AbZEPKKr (ORCPT ); Sat, 16 May 2009 06:10:47 -0400 Received: from 1wt.eu ([62.212.114.60]:1387 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755154AbZEPKKp (ORCPT ); Sat, 16 May 2009 06:10:45 -0400 Date: Sat, 16 May 2009 12:00:39 +0200 From: Willy Tarreau To: Ingo Molnar Cc: 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, "Eric W. Biederman" , Matt Mackall , Dave Jones , James Morris , Andrew Morton , Roland McGrath , de Ven Subject: Re: [Security] [patch] random: make get_random_int() more random Message-ID: <20090516100039.GA24619@1wt.eu> References: <20090505195246.GC21973@elte.hu> <20090505202219.GL31071@waste.org> <20090506103034.GA25203@elte.hu> <20090506162543.GT31071@waste.org> <20090506200954.GA21484@elte.hu> <20090514164737.6eaab4f0@chukar> <20090515134717.GA16389@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090515134717.GA16389@elte.hu> User-Agent: Mutt/1.5.11 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 15, 2009 at 03:47:17PM +0200, Ingo Molnar wrote: > > * Linus Torvalds 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. 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. Willy