[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: |
Anthony Liguori |
Subject: |
Re: [Qemu-devel] [PATCH 0/6] add paravirtualization hwrng support |
Date: |
Fri, 26 Oct 2012 13:24:06 -0500 |
User-agent: |
Notmuch/0.13.2+93~ged93d79 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu) |
"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.
- [Qemu-devel] [PATCH 0/6] add paravirtualization hwrng support, Anthony Liguori, 2012/10/26
- [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