On Sat, 30 Jul 2016 18:09:22 -0400
Theodore Ts'o [off-list ref] wrote as excerpted:

On Fri, Jul 29, 2016 at 01:31:14PM -0400, Alex Xu wrote:

quoted

When qemu is started with -object rng-random,filename=/dev/urandom,
and immediately (i.e. with no initrd and as the first thing in
init):

1. the guest runs dd if=/dev/random, there is no blocking and tons
of data goes to the screen. the data appears to be random.

2. the guest runs getrandom with any requested amount (tested 1 byte
and 16 bytes) and no flags, it blocks for 90-110 seconds while the
"non-blocking pool is initialized". the returned data appears to be
random.

3. the guest runs getrandom with GRND_RANDOM with any requested
amount, it returns the desired amount or possibly less, but in my
experience at least 10 bytes. the returned data appears to be
random.

I believe that the difference between cases 1 and 2 is a bug, since
based on my previous statement, in this scenario, getrandom should
never block.  

This is correct; and it has been fixed in the patches in v4.8-rc1.
The patch which fixes this has been marked for backporting to stable
kernels:

commit 3371f3da08cff4b75c1f2dce742d460539d6566d
Author: Theodore Ts'o [off-list ref]
Date:   Sun Jun 12 18:11:51 2016 -0400

    random: initialize the non-blocking pool via
add_hwgenerator_randomness() 
    If we have a hardware RNG and are using the in-kernel rngd, we
should use this to initialize the non-blocking pool so that
getrandom(2) doesn't block unnecessarily.
    
    Cc: stable@kernel.org
    Signed-off-by: Theodore Ts'o [off-list ref]

Basically, the urandom pool (now CSRPNG) wasn't getting initialized
from the hardware random number generator.  Most people didn't notice
because very few people actually *use* hardware random number
generators (although it's much more common in VM's, which is how
you're using it), and use of getrandom(2) is still relatively rare,
given that glibc hasn't yet seen fit to support it yet.

Cheers,

					- Ted

Dammit, the one time I track down an actual kernel bug someone's already
fixed it. I'd even bothered to check 4.6 so I figured nobody'd gotten
around to it yet.

Thanks for the excellent explanations though. :)