[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/1] virtio-rng: device to send host entropy to

From: Amit Shah
Subject: Re: [Qemu-devel] [PATCH 1/1] virtio-rng: device to send host entropy to guest
Date: Wed, 16 May 2012 22:58:01 +0530

On (Wed) 16 May 2012 [09:02:03], Anthony Liguori wrote:
> On 05/16/2012 08:53 AM, Daniel P. Berrange wrote:
> >On Wed, May 16, 2012 at 08:48:20AM -0500, Anthony Liguori wrote:
> >>On 05/16/2012 08:45 AM, Daniel P. Berrange wrote:
> >>>On Wed, May 16, 2012 at 08:24:22AM -0500, Anthony Liguori wrote:
> >>>>On 05/16/2012 06:30 AM, Amit Shah wrote:
> >>>>>The Linux kernel already has a virtio-rng driver, this is the device
> >>>>>implementation.
> >>>>>
> >>>>>When Linux needs more entropy, it puts a buffer in the vq.  We then put
> >>>>>entropy into that buffer, and push it back to the guest.
> >>>>>
> >>>>>Feeding randomness from host's /dev/urandom into the guest is
> >>>>>sufficient, so this is a simple implementation that opens /dev/urandom
> >>>>>and reads from it whenever required.
> >>>>>
> >>>>>Invocation is simple:
> >>>>>
> >>>>>   qemu ... -device virtio-rng-pci
> >>>>>
> >>>>>In the guest, we see
> >>>>>
> >>>>>   $ cat /sys/devices/virtual/misc/hw_random/rng_available
> >>>>>   virtio
> >>>>>
> >>>>>   $ cat /sys/devices/virtual/misc/hw_random/rng_current
> >>>>>   virtio
> >>>>>
> >>>>>There are ways to extend the device to be more generic and collect
> >>>>>entropy from other sources, but this is simple enough and works for now.
> >>>>>
> >>>>>Signed-off-by: Amit Shah<address@hidden>
> >>>>
> >>>>It's not this simple unfortunately.
> >>>>
> >>>>If you did this with libvirt, one guest could exhaust the available
> >>>>entropy for the remaining guests.  This could be used as a mechanism
> >>>>for one guest to attack another (reducing the available entropy for
> >>>>key generation).
> >>>>
> >>>>You need to rate limit the amount of entropy that a guest can obtain
> >>>>to allow management tools to mitigate this attack.
> >>>
> >>>Ultimately I think you need to have a push mechanism, where an external
> >>>process feeds entropy to QEMU, rather than a pull mechanism where QEMU
> >>>grabs entropy itself.
> >>
> >>A previous patch didn't open urandom directly but instead talked to
> >>an entropy daemon.  This approach would allow libvirt to hand out
> >>entropy as it saw fit without requiring a new driver.
> >
> >The nice thing about just using a plain chardev backend for virtiorng
> >is that it would let you have the flexibility to integrate with any kind
> >of entropy daemon, or even just run without a daemon&  rely on some other
> >process to periodically open the chardev&  feed in data.
> Ack.
> But there is an entropy daemon that does use a protocol.  The
> protocol may be "just read raw random data" but we should at least
> check to make sure that is the protocol.

Yes, that's egd.  Ultimately, we'll use that, but there are more
problems to be solved, both in qemu and in Linux, before we get there
(as described in the previous mails).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]