Messages in this thread |  | | Date | Thu, 17 May 2018 22:32:09 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: Linux messages full of `random: get_random_u32 called from` |
| |
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:
commit edc1c90cb972fdca1f66be5a8e2b0706bd2a4949 Author: Karel Zak <kzak@redhat.com> Date: Tue Mar 20 14:17:24 2018 +0100
lib/randutils: don't break on EAGAIN, use usleep() The current code uses lose_counter to make more attempts to read random numbers. It seems better to wait a moment between attempts to avoid busy loop (we do the same in all-io.h). The worst case is 1 second delay for all random_get_bytes() on systems with uninitialized entropy pool -- for example you call sfdisk (MBR Id or GPT UUIDs) on very first boot, etc. In this case it will use libc rand() as a fallback solution. Note that we do not use random numbers for security sensitive things like keys or so. It's used for random based UUIDs etc. Addresses: https://github.com/karelzak/util-linux/pull/603 Signed-off-by: Karel Zak <kzak@redhat.com>
commit a9cf659e0508c1f56813a7d74c64f67bbc962538 Author: Carlo Caione <carlo@endlessm.com> Date: Mon Mar 19 10:31:07 2018 +0000
lib/randutils: Do not block on getrandom() In Endless we have hit a problem when using 'sfdisk' on the really first boot to automatically expand the rootfs partition. On this platform 'sfdisk' is blocking on getrandom() because not enough random bytes are available. This is an ARM platform without a hwrng. We fix this passing GRND_NONBLOCK to getrandom(). 'sfdisk' will use the best entropy it has available and fallback only as necessary. Signed-off-by: Carlo Caione <carlo@endlessm.com>
Interestingly, these commits in util-linux landed *before* the patches to address CVE-2018-1108 appeared in the kernel in April 2019. This was because the issue of libuuid was blocking on a handful of embedded systems even for we made this change in Linux's random driver. (It just made this problem more likely to be visbile on a larger number of systems; but it was always there.)
- Ted
|  |