lkml.org 
[lkml]   [2017]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2017-08-16 11:57    [W:0.544 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site