Ian Molton wrote: > 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.
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? > > 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 That's a fine reason. > - 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. Wouldn't it be trivial to run egd on the guest, talking over the recent virtio-serial driver to egd on the host? > > 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. I agree with you on that. > 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, unless there's something you're not saying about it. Does it need tell the host how much entropy it needs, or does it just trickle through, stealing host entropy when it doesn't need it, and stalling the guest when the trickle isn't enough? 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. -- Jamie
