On Sat, May 05, 2018 at 02:11:59AM +0200, Piotr Jurkiewicz wrote:
> Package: e2fsprogs
> Version: 1.44.1-2
>
> Trying to mkfs.ext4 from initramfs (so with klibc) inside QEMU, it gets
> stuck on getrandom syscall. Running it with strace:
>
> I wasn't experiencing such a behavior one month before, but I don't know
> what caused it: kernel update from 4.15 to 4.16 or e2fsprogs update.
The immediate cause is that you upgraded to a kernel (probably 4.16.4)
with the patches to CVE-2018-1108 (which was reported by Google's
Project Zero).
commit 43838a23a05fbd13e47d750d3dfd77001536dd33
Author: Theodore Ts'o <ty...@mit.edu>
Date: Wed Apr 11 13:27:52 2018 -0400
random: fix crng_ready() test
The crng_init variable has three states:
0: The CRNG is not initialized at all
1: The CRNG has a small amount of entropy, hopefully good enough for
early-boot, non-cryptographical use cases
2: The CRNG is fully initialized and we are sure it is safe for
cryptographic use cases.
The crng_ready() function should only return true once we are in the
last state. This addresses CVE-2018-1108.
Reported-by: Jann Horn <ja...@google.com>
Fixes: e192be9d9a30 ("random: replace non-blocking pool...")
Cc: sta...@kernel.org # 4.8+
Signed-off-by: Theodore Ts'o <ty...@mit.edu>
Reviewed-by: Jann Horn <ja...@google.com>
The simple workaround is that you build your guest kernel with
CONFIG_HW_RANDOM_VIRTIO enabled, and then make sure QEMU is making a
virtio-rng device enabled. A simple way to do this is to add the
following the QEMU command line:
-object rng-trandom,filename=/dev/urandom,id=rng0 \
-device virtio-rng-pci,rng=rng0
> mkfs.ext4 -U 08365ab2-bf18-43eb-9035-ce947f4a7565 -E hash_seed=08365a
> b2-bf18-43eb-9035-ce947f4a7565 /dev/sda
>
> I don't think mke2fs should do blocking random calls. /dev/urandom is
> present and works fine (I checked it).
mke2fs is not directly doing a blocking random mcall. It's calling
the UUID library, and the UUID library is using the getrandom(2)
system call. This system call blocks when the initial entropy pool
has not yet been initialized, and after that, it does not block at
all.
Does the UUID library need cryptographic randomness when it generates
its UUID? Well, it depends on the user of said library. There are
libraries that depend on the UUID generated by libuuid to be random
and not guessable.
As far as mke2fs is concerned, there are cases where people *do* want
the UUID to be unique, and if you generate the UUID using a
not-yet-fully-initialized random number generator there is a chance
(probably small) that you might get duplicate UUID's.
So anyway, the cause of what you saw was:
1) You upgraded to a kernel which no longer erroneously reports the
CRNG is fully initialized when it wasn't.
2) Your VM and/or your Host doesn't use/provide virtio-rng to get
random entropy passed from the host to the guest.
3) mke2fs calls the UUID library to get random UUIDs. It uses one for
the file system UUID, and another as a secret directory hash to
prevent a potential denial of service attack by a malicious user.
4) The UUID library uses getrandom(2) which is intended to provide
cryptographic-grade security. As such, it blocks until the entropy
pool is considered initialized.
Note: Using getrandom(2) instead of /dev/urandom is considered best
practice, because of there are programs which generate long-term
secrets that must be secure during early system startup, it's possible
that they will generate insecure RSA keys. See [1] for an example of
what can happen when the entropy pool is not fully initialized before
RSA keys get generated.
[1] https://factorable.net/paper.html
Cheers,
- Ted
