Re: Linux messages full of `random: get_random_u32 called from`

[Trent Piepho <tpiepho@impinj.com>]

On Thu, 2018-05-17 at 22:32 -0400, Theodore Y. Ts'o wrote:
> On Fri, May 18, 2018 at 01:27:03AM +0000, Trent Piepho wrote:
> > I've hit this on an embedded system.  mke2fs hangs trying to format a
> > persistent writable filesystem, which is where the random seed to
> > initialize the kernel entropy pool would be stored, because it wants 16
> > bytes of non-cryptographic random data for a filesystem UUID, and util-
> > linux libuuid calls getrandom(16, 0) - no GRND_RANDOM flag - and this
> > hangs for over four minutes.
> 
> This is fixed in util-linux 2.32.  It ships with the following commits:

I feel like "fix" might overstate the result a bit.

This ends up taking a full second to make each UUID.  Having gone to
great effort to make an iMX25 complete userspace startup in 250 ms, a
full second, per UUID, in early startup is pretty appalling.

Let's look at what we're doing after this fix:
Want non-cryptographic random data for UUID, ask kernel for it.
Kernel has non-cryptographic random data, won't give it to us.
Wait one second for cryptographic random data, which we didn't need.
Give up and create our own random data, which is non-cryptographic and
even worse than what the kernel could have given us from the start.

util-linux falls back to rand() seeded with the pid, uid, tv_sec, and
tv_usec from gettimeofday().  Pretty bad on an embedded system with no
RTC and worse than what the kernel in crng_init 1 state can give us.

What took microseconds now takes a seconds.  We have lower quality
random data than we had before.

Seems like two steps backward.  Can't we do better?

How about adding a flag to getrandom() that allows the kernel to return
low-quality data if high-quality data would require blocking?

It would seem to be a fact that there will be users of non-
cryptographic random data in early boot.  What is the best practice for
that?  To fall back to each user trying "to find randomly-looking
things on an 1990s Unix."  That doesn't seem good to me.  But what's
the better way?