Il 26/10/2012 18:09, H. Peter Anvin ha scritto: > 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.
That would be something we can communicate via virtio-rng-pci feature bits. Perhaps /dev/hwrng could also expose a need-whitening property in sysfs. > b) if the host has no physical hwrng, /dev/hwrng will output nothing at > all, which is worse than /dev/random in that situation. Not really, it would just mean that the guest takes more time to gather entropy, just like if you had no virtio-rng-pci at all. > 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.) Yes, migration is a good reason. > 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. Yes, but the agreed solution right now is that programs should not ask for more than 32 bytes or so from /dev/random. Which means /dev/random is not a suitable backend for virtio-rng-pci as things stand now. Paolo
