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 at 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. Patch 2 aims to fix the corner case when the /dev/urandom read fails for whatever reason: we just try once more in this case, since it should only happen when the call is interrupted by a signal. This is not 100% bullet proof, I am happy to hear any suggestions or whether we just don't care about that very rare case. Please have a look! Cheers, Andre Changelog v2 ... v3: - clamp request size on retry to 256 bytes Changelog v1 ... v2: - Drop O_NONBLOCK from the /dev/urandom open() call - Drop block/unblock sequence after failed read, just retry once Andre Przywara (2): virtio/rng: switch to using /dev/urandom virtio/rng: return at least one byte of entropy virtio/rng.c | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) -- 2.25.1
