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:
Author: Karel Zak <k...@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.
Signed-off-by: Karel Zak <k...@redhat.com>
Author: Carlo Caione <ca...@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 <ca...@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.)