From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752933Ab2G1CtM (ORCPT ); Fri, 27 Jul 2012 22:49:12 -0400 Received: from terminus.zytor.com ([198.137.202.10]:54123 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752772Ab2G1CtL (ORCPT ); Fri, 27 Jul 2012 22:49:11 -0400 Message-ID: <5013530D.5080001@zytor.com> Date: Fri, 27 Jul 2012 19:48:45 -0700 From: "H. Peter Anvin" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: "Theodore Ts'o" , linux-kernel@vger.kernel.org, Linus Torvalds , Ingo Molnar , w@1wt.edu, ewust@umich.edu, zakir@umich.edu, greg@kroah.com, mpm@selenic.com, nadiah@cs.ucsd.edu, jhalderm@umich.edu, tglx@linutronix.de, davem@davemloft.net, stable@vger.kernel.org, DJ Johnston , "H. Peter Anvin" Subject: Re: [PATCH] random: mix in architectural randomness in extract_buf() References: <20120725151000.GA30996@thunk.org> <1343237822-7789-1-git-send-email-hpa@zytor.com> <20120728023938.GA3766@thunk.org> In-Reply-To: <20120728023938.GA3766@thunk.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/27/2012 07:39 PM, Theodore Ts'o wrote: > Ok, I'll add this patch to the random tree. I've modified the commit > message a bit since the speed advertisement of RDRAND is rather > pointless --- processes aren't generating session keys or long term > keys at a high rate, and programs can't count on /dev/random being > super fast and having unlimited entropy, since for most platforms and > even most x86 CPU's deployed in service today, this isn't true --- and > making your userspace program depond upon /dev/random in such a way > that it only works on Ivy Bridge CPU's might be good for Intel from a > vendor lock-in perspective, but it's really bad, non-portable > programming style. > > Also, in the future arch_get_random_long() will almost certainly be > hooked up for other architectures, so putting an extended > advertisement for RDRAND really isn't appropriate. Thanks. /dev/random vs /dev/urandom is orthogonal to this; as you note we still haven't changed the entropy accounting. I am thinking that that is probably better left to rngd at least until RDSEED is available (or the equivalent on other hardware.) -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.