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: <20170815142528.ne5fewtrnazmjzt6@thunk.org>
Date:   Tue, 15 Aug 2017 10:25:28 -0400
From:   Theodore Ts'o <tytso@....edu>
To:     Thomas Gleixner <tglx@...utronix.de>
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, 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).

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.

3)  Depending on when you use this function in early boot, udelay()
might not even have been calibrated yet.

4) As as standalone function, it doesn't take advantage of whatever
randomness might have been available; and if it turns out that the
tsc_early_random() is trivially predictable by someone spends more
time analyizing it for particular target architectures, it could be
disastrous

5) If you use this in addition to the existing get_random_u32(), it
won't hurt from a cryptographic perspective, but it will end up
burning 64-128 microseconds (or potentially more, depending on how
udelay is implemented on the architecture/subarch and whether udelay
has been calibrated yet).  And it's not clear it's really better(tm).

6) It would be the ultimate in irony if Jason, who tried so hard to
get this warning in because he hoped it would make Linux more secure,
actually ends up making Linux *less* secure because something like
this starts getting used....

					- Ted