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

[Paolo Bonzini <pbonzini@redhat.com>]

Il 30/10/2012 22:11, H. Peter Anvin ha scritto:
>> What I said that passing /dev/hwrng or rdrand would:
>>
>> - not make /dev/random with virtio-rng-pci worse than without
> 
> It wouldn't, but it would make virtio-rng-pci a potential noop on a
> system where it could genuinely do better.

True, but it can be fixed later without changing the guest hardware.  It
will just perform better, transparently.

>> - make migration working
>>
>> - avoiding denial of service for the host's /dev/random
> 
> However, it means that if there is an rngd-readable source on the host
> (e.g. TPM, DRNG) then the guest cannot take advantage of it;

Right.  A DRNG backend for virtio-rng-pci however can easily be
implemented in QEMU.  In this case you do have a slowish roundtrip to
the host, but only if you need to migrate to older hosts (hopefully not
a concern in smaller deployments---or in a few years).

Related to this, rdrand's "entropy content" in the worst case will be
only 1/255th of the data it produces: Intel documents that one 256-bit
seed will result in up to 1022 64-bit random numbers.  Yet, it is good
enough to drive rngd.  Would it make sense for QEMU to implement the
same kind of stretching of /dev/random data, to avoid depleting the
host's entropy pool too fast?

> Furthermore, you are in many ways still causing a DoS on the host, since
> you are eating up entropy that would otherwise be fed into /dev/random.
> So there are cases where the situation is much worse with /dev/hwrng
> than with /dev/random.

How is it worse, at least from the host point of view?  At least the
entropy bits collected by the kernel will remain untouched.  From the
guest point of view it doesn't have to be too good, as long as it's not
/dev/urandom.

If you know you won't run any task that requires /dev/random on the
host, and/or you somehow trust the guests, you certainly can pass it to
the guests and disable the test in rngd.  However, the same
configuration needs to be applied to all hosts, because the
test-disabled feature bit must not go from 1 to 0 over migration.

Paolo