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

Message-ID: <alpine.DEB.2.20.1708151638160.1886@nanos>
Date:   Tue, 15 Aug 2017 16:42:47 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Theodore Ts'o <tytso@....edu>
cc:     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>
Subject: Re: early x86 unseeded randomness

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.

> 2) Given a dozen numbers and saying, "hmm, my human brain doesn't see
> a problem, it *must* be good" is hardly the basis on which to make
> this kind of security design.  If you don't understand why this is a
> bad idea, and can't come up with a counter example in under 5 seconds,
> you probably aren't qualified to be designing a RNG which is supposed
> to be cryptographically secure.

Care to read the paper?

We tried that 6 years ago on a wide range of machines from server to stupid
first generation in order ATOM chips. All of them exposed more or less the
same behaviour and passed RND validation tests.

I'm not saying it's a replacement for the run time random generator, but
it's exceptionally good and reasonably fast for the early boot
randomization.

Thanks,

	tglx