Re: [PATCH] random: reseed in RNDRESEEDCRNG for the !crng_ready() case

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

On Mon, Jan 03, 2022 at 05:00:02PM +0100, Jason A. Donenfeld wrote:
> Userspace often wants to seed the RNG from disk, without knowing how
> much entropy is really in that file. In that case, userspace says
> there's no entropy, so none is credited. If this happens in the
> crng_init==1 state -- common at early boot time when such seed files are
> used -- then that seed file will be written into the pool, but it won't
> actually help the quality of /dev/urandom reads. Instead, it'll sit
> around until something does credit sufficient amounts of entropy, at
> which point, the RNG is seeded and initialized.
> 
> Rather than let those seed file bits sit around unused until "sometime
> later", userspaces that call RNDRESEEDCRNG can expect, with this commit,
> for those seed bits to be put to use *somehow*. This is accomplished by
> extracting from the input pool on RNDRESEEDCRNG, xoring 32 bytes into
> the current crng state.

I think this is fine, but the RNDRESEEDRNG ioctl is rarely used by
userspace.  From a Google search I see that jitterentropy uses it, but
in most setups it won't be called.

So something we could do to improve things is to add some code to
random_write() so that in the case where crng_init is 1, we take half
of the bytes or CHACHA_KEY_SIZE bytes, whichever is less, and pass
those bytes to crng_fast_load().  (We'll have to copy it to a bounce
buffer since the passed in pointer is __user, and memzero_explicit it
after calling crng_fast_load.)

This will divert some part of the seed file to partially initialize
the CRNG.  It won't fully initialize the CRNG, but that's fine, since
it's possible that the seed file has been compromised --- or is a
fixed value if the seed file is from coming a VM image file.  So
having at least half of the entropy used to initialize CRNG up to
crng_init=1 is coming from interrupt timing seems like a good thing.

					- Ted