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?
