On Sat, 30 Jul 2016 18:09:22 -0400 Theodore Ts'o <ty...@mit.edu> wrote as excerpted: > On Fri, Jul 29, 2016 at 01:31:14PM -0400, Alex Xu wrote: > > 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 <ty...@mit.edu> > 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: sta...@kernel.org > Signed-off-by: Theodore Ts'o <ty...@mit.edu> > > 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. :) -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
