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

[H. Peter Anvin]

This is surreal.  Output from /dev/hwrng turns into output for /dev/random... 
it us guaranteed worse; period, end of story.

I don't know who the "agreement" is with, but it is ridiculous in this case.

As far as the need whitening issue, I discussed that with Ted at Kernel Summit 
and we came up with an outline for what we can do to improve the current 
situation.  It is challenging to deal with the patanoia crowd at the same time.

Paolo Bonzini <address@hidden> wrote:

>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

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.