Jamie Lokier wrote:
> Ian Molton wrote:
>> Jamie Lokier wrote:
>>> What do the other hypervisors supporting virtio-rng do?
>> Um. support it? Im not sure what you mean there.
>
> Do the other hypervisors do anything special to support EGD, or is it
> just treated as another kind of serial port connected to /dev/urandom
> (or whatever) on the host?
They treat it as a paravirtualised PCI RNG device :-)
The hypervisor reads /dev/{u,}random *only* in at least one
implementation (or did at the time of writing and I doubt its changed).
It was, IIRC, somewhat criticised for not applying rate limiting in the
hypervisor, allowing one guest to steal all the hosts available entropy
- something I sought to avoid in my implementation.
However thats a hypervisor issue, not a protocol issue. The fact is that
the kernel has a channel for receiving RNG data from a hypervisor. That
channel is virtio-rng.
Yes one can do it other ways. In fact the whole reason I wrote the code
is because people who *are* doing it 'other ways' wanted it done this
way, like the other hypervisors.
> Wouldn't it be trivial to run egd on the guest, talking over the
> recent virtio-serial driver to egd on the host?
Yes, but that isn't the point. Many problems have more than one
solution. Using virtio-rng means that the data is going into the guest
kernels hwrng subsystem. Wether this is the right way or not for a given
user really isnt for me or anyone else to argue - its more than
efficient enough, and it means that the exact same tools that run on
machines with actual RNG hardware can be used without change. If nothing
else, its good for testing those tools.
>> Why even bother with virtio at all if you're going to abstract
>> everything away behind a serial port? we could just modify all the guest
>> kernel virtio-block drivers to serialise all their metadata, then we
>> could use serial ports for that too!
>
> No, the point is virtio-rng *is* already a byte stream. It's already
> a perfect match for a serial port,
Sure, *any* byte stream would be. thats what serial ports /do/.
But its just not the point. Im not here to argue if one solution or
another is the worlds best One True Way (tm). I've merely implemented
one solution in qemu that other hypervisors *AND* the kernel already
support, and that users want. Its non-invasive. It performs well. It
passes FIPS-140. What more could anyone want? Not including a feature
beacuse you might do it differently is simply not an argument, unless
your solution is better in some way, like, say, it performs massively
better, or its hugely smaller... so lets see!
Pros:
virtio-rng
------------
* uses pre-existing kernel infrastructure
* quick
* tested to pass FIPS-140 (statistically no worse than the host
natively (FIPS-140 is a probabalistic
test, some failures are the nature of
the beast))
* very small driver (smaller than a serial driver + serial core
* does not require virtio-serial core
* does not require unusual and untested daemons on the guest
virtio-serial
-------------
* um. Help me out here?
Cons:
virtio-rng
-------------
* I guess if you have it *and* the virtio-serial core, its a tiny
bit bigger. *But* thats probably offset by not needing a special
daemon on the guest, so not really a point...
virtio-serial
-------------
* support daemons not written yet or abusing other daemons in ways that
aren't commonly done.
* untested (believe me, its easy to provoke subtle FIPS-140 FAILs)
* requires the use of the virtio-serial core even if no other serial
drivers are in use (overkill).
* Impossible to interface with the kernels hwrng core and thus
useless for debugging it and related tools on the guest.
> If it's dumb enough to just trickle the entropy through, that would
> seem a very good match to virtio-serial - apart from the guests which
> already expect virtio-rng support. ^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Isn't that latter feature a good enough reason on its own? qemu supports
a LOT of obscure hardware already - so "its weird" is also NOT a good
reason against it. And its not even weird or unusual in this instance.
If qemu is only to support one way of doing any given operation then we
should get rid of a LOT of other drivers - like most of the video
drivers for example, and IDE/SCSI/SATA - well, all guests should just
use virtio-block, right?
:-D
-Ian
