Re: early x86 unseeded randomness

[Thomas Gleixner <tglx@linutronix.de>]

On Tue, 15 Aug 2017, Thomas Gleixner wrote:
> On Tue, 15 Aug 2017, Theodore Ts'o wrote:
> > On Tue, Aug 15, 2017 at 03:48:18PM +0200, Thomas Gleixner wrote:
> > > > > +u64 __init tsc_early_random(void)
> > > > > +{
> > > > > +	u64 uninitialized_var(res);
> > > > > +	int i;
> > > > > +
> > > > > +	if (!boot_cpu_has(X86_FEATURE_TSC))
> > > > > +		return res;
> > > > > +
> > > > > +	res ^= rdtsc();
> > > > > +	for (i = 0; i < BITS_PER_LONG; i++) {
> > > > > +		res ^= ((rdtsc() & 0x04) >> 2) << i;
> > > > > +		udelay(2);
> > > > > +	}
> > > > > +	return res;
> > > > > +}
> > 
> > Reasons why this is probably not the best idea:
> > 
> > 1)  Exactly how udelay is implemented varies from architecture to
> > architecture and in some cases is different on a subarchitectural
> > level.  Some of them rely on reading the TSC; others rely on
> > operations that will have a constant number of CPU cycles (e.g., they
> > aren't doing much if any operations that might even have a tiny
> > glimmer of hope of adding unpredictability).
> 
> That's not really true. You can add random shite instead of udelay(2). The
> point of this exercise is to somewhat utilize the instruction pipeline,
> which causes the TSC readouts to be not even spread over a the loop and
> therefor yield random results.

Talking about random shite:

    	memset(foo, 0, sizeof(foo));
	res ^= rdtsc();
	for (i = 0; i < BITS_PER_LONG; i++) {
		/* Will never happen ... */
		if (memchr_inv(foo, i, sizeof(foo)))
			continue;
		res ^= ((rdtsc() & 0x04) >> 2) << i;
		memset(foo, i, sizeof(foo));
		wbinvd();
	}
	return res;

That exploits the fact that the CPU and caches run at a different non
synchronized clock than the memory controller and therefore the execution
time for both the wbinvd() and the memchr_inv() measured in TSC cycles is
non constant and random enough for the early boot randomization.

Thanks,

	tglx