Il 02/02/2013 00:40, Matthew Garrett ha scritto: > This patchset means that there's a /dev/hwrng available in the guest, so > you still need to run something like rngd to mix that into the kernel's > entropy pool. You're right that the total amount of entropy is still > limited to that available on the host, and it does make host-side > exhaustion more likely. There's not a lot that can be done about that > other than providing other sources of entropy, and long-term this is > going to be fixed once everyone's moved to Ivy Bridge and has an > unprivileged instruction to hand out entropy. If you're talking about RDRAND, it doesn't hand out entropy. That's RDSEED, which will only come with Haswell. RDRAND only hands out random numbers. We plan to add QEMU support for using RDRAND directly (with whitening, similar to rngd), but it is not in yet. Right now what you do is use rngd in the host to feed /dev/random with random numbers from RDRAND, connect /dev/random to virtio-rng. In either case, in the end the guest will have to run rngd to feed the entropy into virtio-rng. BTW, virtio-rng really only works well if you have a hardware RNG in the host. Otherwise, the host kernel will take too much time (a few minutes) before producing enough entropy to feed the FIPS tests in the guest, and during this time the host will be entropy-starved. Paolo >> Given FIPS paranoia about RNG sources, does this have knock-on effects in >> the FIPS compliance of guests depending on how it's fed in the host? > > I'm not convinced that you could currently claim with a straight face > that guests meet any sort of FIPS standard for random numbers. > -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
