At the moment kvmtool uses the /dev/random device to back the randomness provided by our virtio/rng implementation. We run it in non-blocking mode, so are not affected by the nasty "can block indefinitely" behaviour of that file. However: - If /dev/random WOULD block, it returns EAGAIN, and we reflect that by adding 0 bytes of entropy to the virtio queue. However the virtio 1.x spec clearly says this is not allowed, and that we should always provide at least one random byte. - If the guest is waiting for the random numbers, we still run into an effective blocking situation, because the buffer will only be filled very slowly, effectively stalling or blocking the guest. EDK II shows that behaviour, when servicing the EFI_RNG_PROTOCOL runtime service call, called by the kernel very early on boot. Those two patches fix those problems, and allow to boot a Linux kernel MUCH quicker when the host lacks good entropy sources. On a particular system the kernel took 10 minutes to boot because of /dev/random effectively blocking, this runs now in full speed. The block is avoided by using /dev/urandom, there is a proper rabbit hole in the internet out there why this is safe, even for cryptographic applications. I am not sure we now really need patch 2 anymore (originally I had this one before I switched to /dev/urandom). I *think* even a read from /dev/urandom can return early (because of a signal, for instance), so a return with 0 bytes read seems possible. Please have a look! Cheers, Andre Andre Przywara (2): virtio/rng: switch to using /dev/urandom virtio/rng: return at least one byte of entropy virtio/rng.c | 33 ++++++++++++++++++++++++++++++--- 1 file changed, 30 insertions(+), 3 deletions(-) -- 2.25.1
