[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 0/6] add paravirtualization hwrng support
From: |
H. Peter Anvin |
Subject: |
Re: [Qemu-devel] [PATCH 0/6] add paravirtualization hwrng support |
Date: |
Fri, 26 Oct 2012 11:26:36 -0700 |
User-agent: |
K-9 Mail for Android |
PRNGs don't "create entropy." Period.
The guest will run its own PRNG.
Anthony Liguori <address@hidden> wrote:
>"H. Peter Anvin" <address@hidden> writes:
>
>> 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."
>
>I don't understand your logic here.
>
>From the discussions I've had, the quality of the randomness from a
>*well seeded* PRNG ought to be good enough to act as an entropy source
>within the guest.
>
>What qualifies as well seeded is a bit difficult to pin down with more
>specificity than "kilobytes of data".
>
>I stayed away from /dev/urandom primarily because it's impossible to
>determine if it's well seeded or not making urandom dangerous to use.
>
>But using a PRNG makes sense to me when dealing with multiple guests.
>If you have a finite source of entropy in the host, using a PRNG to
>create unique entropy for each guest is certainly better than
>duplicating entropy.
>
>Adding Ted T'so and a few others to CC in hopes that they can chime in
>here too.
>
>FWIW, none of this should affect this series being merged as it can use
>a variety of different inputs. But I would like to have a strong
>recommendation for what people should use (and make that default) so
>I'd
>really like to get a clear answer here.
>
>Regards,
>
>Anthony Liguori
>
>>
>> /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.
--
Sent from my mobile phone. Please excuse brevity and lack of formatting.
- [Qemu-devel] [PATCH 3/6] rng: add RndBackend abstract object class, (continued)
- [Qemu-devel] [PATCH 3/6] rng: add RndBackend abstract object class, Anthony Liguori, 2012/10/26
- [Qemu-devel] [PATCH 5/6] rng-egd: introduce EGD compliant RNG backend, Anthony Liguori, 2012/10/26
- [Qemu-devel] [PATCH 2/6] object: add object_property_add_bool (v2), Anthony Liguori, 2012/10/26
- [Qemu-devel] [PATCH 6/6] virtio-rng: hardware random number generator device, Anthony Liguori, 2012/10/26
- [Qemu-devel] [PATCH 1/6] vl: add -object option to create QOM objects from the command line, Anthony Liguori, 2012/10/26
- [Qemu-devel] [PATCH 4/6] rng-random: add an RNG backend that uses /dev/random, Anthony Liguori, 2012/10/26
- Re: [Qemu-devel] [PATCH 0/6] add paravirtualization hwrng support, Paolo Bonzini, 2012/10/26
- Re: [Qemu-devel] [PATCH 0/6] add paravirtualization hwrng support, Paolo Bonzini, 2012/10/26
- Re: [Qemu-devel] [PATCH 0/6] add paravirtualization hwrng support, H. Peter Anvin, 2012/10/26
- Re: [Qemu-devel] [PATCH 0/6] add paravirtualization hwrng support, Paolo Bonzini, 2012/10/26
- Re: [Qemu-devel] [PATCH 0/6] add paravirtualization hwrng support, H. Peter Anvin, 2012/10/26
- Re: [Qemu-devel] [PATCH 0/6] add paravirtualization hwrng support, H. Peter Anvin, 2012/10/26
- Re: [Qemu-devel] [PATCH 0/6] add paravirtualization hwrng support, Paolo Bonzini, 2012/10/29
- Re: [Qemu-devel] [PATCH 0/6] add paravirtualization hwrng support, H. Peter Anvin, 2012/10/30
- Re: [Qemu-devel] [PATCH 0/6] add paravirtualization hwrng support, H. Peter Anvin, 2012/10/30