From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751767AbdHPJ4k (ORCPT ); Wed, 16 Aug 2017 05:56:40 -0400 Received: from foss.arm.com ([217.140.101.70]:33170 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751212AbdHPJ4i (ORCPT ); Wed, 16 Aug 2017 05:56:38 -0400 Date: Wed, 16 Aug 2017 10:56:38 +0100 From: Will Deacon To: Thomas Gleixner Cc: "Theodore Ts'o" , Borislav Petkov , Ingo Molnar , Willy Tarreau , Linus Torvalds , x86-ml , "Jason A. Donenfeld" , lkml , Peter Zijlstra , Nicholas Mc Guire , paulmck@linux.vnet.ibm.com Subject: Re: early x86 unseeded randomness Message-ID: <20170816095637.GF12845@arm.com> References: <20170815064437.GA1986@1wt.eu> <20170815074254.6byayhspc5tdtjb5@gmail.com> <20170815134514.r6qjotjgfmurwh64@pd.tnic> <20170815142528.ne5fewtrnazmjzt6@thunk.org> <20170816033517.25pwmuleyrjrod26@thunk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 16, 2017 at 11:13:03AM +0200, Thomas Gleixner wrote: > On Tue, 15 Aug 2017, Theodore Ts'o wrote: > > If we really want to do this, I'd much rather *not* have code calling > > tsc_early_random(). We're better off having the code call > > get_random_bytes() and/or get_random_u32(), and having these systems > > use RDRAND if available, and if not, falling back to > > tsc_early_random() and then mixing it with whatever unpredictability > > we may have been able to gather so far if the CRNG hasn't been > > initialized yet. > > I agree. This is not about systems which have RDRAND. We want to support > systems which do not have it and there the TSC magic comes handy. > > > That way something like tsc_early_random() can help, but it can't make > > things worse than what we have today (excepting the performance delay > > caused by adding whatever random shite that we hope is enough to > > introduce unpredictability to the TSC --- for which I still remain > > very skeptical). > > I just rerun tests in the early boot code (interrupts disabled, no NMIs > ...) with the TSC/wbinvd voodoo on several generations of machines and > stored 4M random values in a big static array. Reading it out after boot > and running it through dieharder makes me pretty confident that we observe > real random noise coming from the internals of the microarch/pipelines/bus > interactions. > > > P.S. As I recall hpa@ has talked to some Intel architects internally > > about how much unpredictability we could really get, and how much of > > it is just because there's complex state that we can't see (which if > > we could see, might make it much more predictable), and as I recall > > Right, there is complex state which is not completely synchronous even if > all frequencies are derived from a single 24MHZ oscillator. The PWMs, the > memory access characteristics and quite some other sources of > asynchronousity allow us to utilize that and I'm pretty sure, that you > can't find two systems which expose exactly the same behaviour. > > > they didn't say anyhing definitively; but they were nervous. I'm > > Sure, they are always nervous when you ask them questions about the > internals of their chips especially when you expect authorative answers. Right, especially as this is randomness as a side-effect of the design, rather than something that was an actual design goal. You won't find CPU designers committing to semantics of accidental behaviours :) Another paper on this (which I think Paul pointed me to) is: https://www.kernel.org/doc/ols/2014/ols2014-mueller.pdf which seems to be what crypto/jitterentropy.c is based on. On arm64, we currently rely on the bootloader for entropy (either an explicit kaslr seed, or the EFI_RNG_PROTOCOL). Unfortunately, the former is often zero and the latter unimplemented, but this seems to be improving slowly. Will