Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG

[Ian Molton]

Jamie Lokier wrote:

Hi :-)

> Ian Molton wrote:
>> One last and quite important point - where should the EGD protocol
>> implementation go? really it needs to work as kind-of a line discipline,
>> but AFAICT thats not supported? it would be a mistake to put rate
>> limiting in the chardev layer and leave the EGD protocol implementation
>> in the driver.
> 
> What do the other hypervisors supporting virtio-rng do?

Um. support it? Im not sure what you mean there.

> Personally I'm failing to see why EGD support is needed in Qemu, as
> none of the crypto services on my Linux machines seem to need it so
> why should Qemu be special, but I acknowledge there might be some
> obscure reason.

I know seevral people who use egd based hardware on their hosts who want
 virtio-rng support in their guests - it avoids having to route the data
via TCP or other long winded paths that are trivially vulverable to
attack both on the host and from the guests userspace. The hwrng core is
inherently very simple.

>> TBH, for the sake of one very simple driver, and given that apparently
>> no other users in qemu seem to want rate-limiting, *I( think that you
>> are massively over-complicating matters right now. If more drivers need
>> rate limiting, perhaps, but that doesnt seem to be the case.
> 
> Rate limiting both networking and serial ports may be a handy little
> option sometimes.

Perhaps, but I'm not a big user of those systems and as such Im not
really in a position to design a rate limiting algorithm thats going to
be really appropriate without spending a lot of time I dont have looking
at stuff I don't really care about.

I don't mind implementing trivial rate/burst limiting in the chardev
layer if thats whats wanted, but I have neither the time nor inclination
to write a thesis on the subject :-)

>  Iirc, there are some guests which get confused when
> data transfers are gazillions times faster than they expected, or
> gazillions times more bursty in the case of networking.

Realistically, that kind of limiting might be best off in the device
drivers those systems use, which has more intimate knowledge of how the
virtual hardware should behave. Without extensive testing I just couldnt
answer that.

>>> We already have a virtual serial port implementation designed for 
>>> exactly this kind of application.
>> Except that it doesn't speak to the kernels virtio-rng implementation.
>> And that interface is not going to change just because you don't like
>> it. (Unless you'd like to rewrite the kernels hwrng core? feel free! I'm
>> sure it'd be appreciated - but if not, then don't complain)
> 
> Would it be much work to change the guest to use virtio-serial
> instead?  Would it fit the problem or does virtio-rng need more
> metadata than just a bytestream?

If anything virtio-rng uses *less* info than the virtio-serial driver
(it has one stream, in one direction, only).

But the kernel already has a virtio-rng driver and it already works in a
particular way, which is already implemented in other hypervisors. I
didn't write the kernel driver, it is pre-existing. I suppose we could
ask the kernel devs if they'd like another virtio-based rng driver in
addition to the one already in use? but that seems perverse.

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!

Abstraction can be taken too far.

All MHO but I'm standing by what I said. If I can get a reasonable
consensus about rewriting the code so that we get all the features
needed for an enterprise level solution, namely

* Fault tolerance - socket reconnection support.
* EGD protocol support - because its what the users of this code (not me
as such, I don't actually use it at all myself) actually want
* virtio-rng support - because anything else is stupid and would involve
getting a second virtio-serial-rng driver into the kernel.

Then great.

IMHO, the socket reconnect patch and the SIZE parameter patch fix
obvious flaws in qemu and should be applied now, unless someone can come
up with a good reason why they shouldn't.

We can carry on debating the actual virtio-rng driver if thats whats
wanted, but I have stated my position. So far the only argument against
is "well I wouldn't choose to do it that way", which is hardly concrete
reasoning.

Please, please, can we get out of the bikeshed?

-Ian