On 10/26/2012 08:42 AM, Anthony Liguori wrote:
Is /dev/random even appropriate to feed rngd?
rngd needs _a lot_ of entropy to even start working. Its randomness
test works in groups of 20000 bits. On a system without an hardware
RNG, /dev/random can hardly produce 4000 bits/minute. This means a
guest will not get any entropy boost for 5 minutes after it's started,
even if we allow it to exhaust the parent's entropy.
I don't know, but rng-random is a non-blocking backend so it can handle
/dev/random, /dev/urandom, or /dev/hwrng.
/dev/urandom is just plain *wrong*... it is feeding a PRNG into a PRNG
which can best be described as "masturbation" and at worst as a
"cryptographic usage violation."
/dev/hwrng is reasonable, in some ways; after all, the guest itself is
expected to use rngd. There are, however, at least two problems:
a) it means that the guest *has* to run rngd or a similar engine; if you
have control over the guests it might be more efficient to run rngd in
skip-test mode (I don't think that is currently implemented but it
could/should be) and centralize all testing to the host.
A skip-test mode would also allow rngd to forward-feed shorter blocks
than 2500 bytes.
b) if the host has no physical hwrng, /dev/hwrng will output nothing at
all, which is worse than /dev/random in that situation.
Stefan Berger suggested a backend that uses a PRNG in FreeBL. That's
probably the best default since it punts to a userspace library to deal
with ensuring there's adequate whitening/entropy to start with.
We SHOULD NOT expose a PRNG here! It is the same fail as using
/dev/urandom (but worse) The whole point is to inject actual entropy...
a PRNG can (and typically will) just run in guest space.
Maybe rdrand, but that's just a chardev---so why isn't this enough:
-chardev file,source=on,path=/dev/hwrng,id=chr0 -device
virtio-rng-pci,file=chr0
-chardev rdrand,id=chr0 -device
virtio-rng-pci,file=chr0
-chardev socket,host=localhost,port=1024,id=chr0 -device
virtio-rng-pci,rng=chr0,egd=on
(which I suggested in my reply to Amit)?
If you have rdrand you might just use it in the guest directly, unless
you have a strong reason (migration?) not to do that. Either way, for
rdrand you need whitening similar to what rngd is doing (for *rdseed*
you do not, but rdseed is not shipping yet.)
The startup issue is an interesting problem. If you have full control
over the guest it might be best to simply inject some entropy into the
guest on startup via the initramfs or a disk image; that has its own
awkwardness too, of course. The one bit that could potentially be
solved in Qemu would be an option to "don't start the guest until X
bytes of entropy have been gathered."
Overall, I want to emphasize that we don't want to try solve generic
problems in virtualization space... resource constraints on /dev/random
is a generic host OS issue for example.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.