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
