Message-ID: <20170815013124.2afytkibspxrikdn@thunk.org>
Date:   Mon, 14 Aug 2017 21:31:24 -0400
From:   Theodore Ts'o <tytso@....edu>
To:     Borislav Petkov <bp@...en8.de>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        x86-ml <x86@...nel.org>, "Jason A. Donenfeld" <Jason@...c4.com>,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: early x86 unseeded randomness

On Mon, Aug 14, 2017 at 09:00:13PM +0200, Borislav Petkov wrote:
> On Mon, Aug 14, 2017 at 11:17:37AM -0700, Linus Torvalds wrote:
> > Ok, guys, you ALL need to learn that blindly just trying to get rid of
> > warnings IS A HORRIBLE IDEA.
> 
> Not blindly - I was actually suggesting/asking whether falling back to
> the TSC that early during boot might make more sense than using unseeded
> randomness. Especially add the least significant 32 bits to the most
> significant i.e., that thing:
> 
> 	tsc + (tsc << 32UL)
> 
> as they're more unpredictable.

Part of the initialization step of the entropy pools and the crng
mixes in the jiffies, ktime_get_real() and the TSC.  So if you are one
of those people who believe in the magic of jitter-rng, we do
something somewhat similar to that a part of the initialization.  We
just don't credit any entropy to that step.

> 
> > But maybe those places that currently trigger the warning should just
> > use "get_random_u32()" instead. That at least gets rid of the warning
> > if there's a fast architected hardware random thing (ie modern x86).
> 
> Right, that is better, at least for the RDRAND machines.

Also note that the CRNG will use RDRAND if it is there; it just
doesn't depend on it.  The main thing about get_random_u32() is that
it has a policy decision embedded into it which is that we believe
that RDRAND, or whatever implements arch_get_random_{seed_}{long,int} is 
trusted.  (e.g., that we trust that Intel, Qualcomm, etc., didn't put a
back door into CPU-based random number generator, which we basically have
to take on faith because there is no way to audit it).

I tend to be a bit of pragmatist on these things, which is that I
believe it is *unlikely* that the NSA managed to pay off or blackmail
Intel into subverting RDRAND.  I can't prove it, of course, but if we
can get away with not trusting Intel, it's better if we can avoid
investing all of our trust in Intel.  On the flip side, for very early
boot, unless we can do what OpenBSD does and actually embed into the
boot loader reading a cryptographic seed from trusted store, it's
pretty much hopeless to think we can gather entropy, and we might as
well just use RDRAND, and hope for the best.  Realistically speaking,
the harm done from a bogus stack canary or even a subverted KASLR is
very small compared with introducing a wekaness into the keygen of
long-term public/private key.

And yes, spraying warning around just annoys users and if it inspires
them to do dumb(tm) things, it really doesn't help.  So suppressing
warnings during early boot is probably a good thing, since hopefully
people in early boot won't be stupid enough to generate high-value
keypairs.  :-)

>  We'd still need a proper fix for the older ones. And I don't see an
> easy way to change the init ordering for the stack canary as it gets
> setup very very early in start_kernel() vs crng_initialize() being
> an early_initcall()... Need to sleep on it.

The real fix is to do what OpenBSD does, which is to teach the
bootloader (e.g., grub) to read from some file such as
/var/lib/urandom/random-seed, and then to have the init scripts
overwrite it with a new set of entropy generated from getrandom(2) as
early as possible.

It won't solve the CD-ROM install problem (although there is enough
entropy during the install process that after the install is done, we
should be fine, and again, *hopefully* the distro people won't be
stupid enough to generate high-value keys during the installation
process, or certainly not early in the installation process).  But it
does solve most of the problem.

     	   			- Ted

Powered by blists - more mailing lists