Re: [PATCH] random: avoid superfluous call to RDRAND in CRNG extraction

["Theodore Ts'o" <tytso@mit.edu>]

On Thu, Dec 30, 2021 at 11:58:05PM +0100, Jason A. Donenfeld wrote:
> > Or if we want to improve the security of get_random_bytes() pre
> > crng_ready(), then we should try to XOR RDRAND bytes into all returned
> > buffer from get_random_bytes().  In other words, I'd argue that we
> > should "go big, or go home".  (And if we do have some real,
> > security-critical users of get_random_bytes() pre-crng_ready(), maybe
> > "go big" is the right way to go.
> 
> That's a decent way of looking at it. Rather than dallying with
> 32bits, we may as well go all the way. Or, to compromise on
> efficiency, we could just xor in 16 or 32 bytes into the key rows
> prior to each extraction. Alternatively, we have fewer things to think
> about with the "go home" route, and then it's just a matter of
> important users using get_random_bytes_wait(), which I think I mostly
> took care of through the tree a few years back.

I was too lazy to do an audit of all of the get_random_bytes() users
before I wrote my last e-mail, but I'm good with "go home" route ---
especially since actually doing that full audit to make sure we don't
have any pre-crng_ready() security-critical users of
get_random_bytes() would still be important to do on architectures
like RISC-V that don't have a RDRAND equivalent.

The challenge is here is short of making adding a
WARN_ON(!crng_ready()) to get_random_bytes(), it's hard to be sure
that some future security critical user of get_random_bytes() in early
boot won't creep back in.  And last I checked, we still have some
non-security get_random_bytes() users in early boot where the
WARN_ON() isn't going to be welcome.

> - I would like to see if at some point (not now, just in the future)
> it's feasible, performance wise, to replace all of prandom with
> get_batched_random() and company.

That's going to be challenging, I suspect.  Some of the networking
users of prandom() have some *very* strong performance constraints.
Or at least, the networking developers have some benchmarks where they
won't countenance any performance regressions.  When the prandom
implementation was added, some of the networking devs were positively
doing cycle counting to try to trim it down as much as possible....

						- Ted