Re: [Qemu-devel] [PATCH 0/6] add paravirtualization hwrng support

[Paolo Bonzini <pbonzini@redhat.com>]

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