linux-kernel - Re: early x86 unseeded randomness

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] [day] [month] [year] [list]

Message-ID: <20170816095637.GF12845@arm.com>
Date:   Wed, 16 Aug 2017 10:56:38 +0100
From:   Will Deacon <will.deacon@....com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Theodore Ts'o <tytso@....edu>, Borislav Petkov <bp@...en8.de>,
        Ingo Molnar <mingo@...nel.org>, Willy Tarreau <w@....eu>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        x86-ml <x86@...nel.org>, "Jason A. Donenfeld" <Jason@...c4.com>,
        lkml <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Nicholas Mc Guire <der.herr@...r.at>,
        paulmck@...ux.vnet.ibm.com
Subject: Re: early x86 unseeded randomness

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