Messages in this thread |  | | From | Trent Piepho <> | Subject | Re: Linux messages full of `random: get_random_u32 called from` | Date | Fri, 18 May 2018 22:56:18 +0000 |
| |
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? |  |