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

[Ian Molton <ian.molton@collabora.co.uk>]

On 23/04/10 18:32, Jamie Lokier wrote:
> Ian Molton wrote:
>>> You can configure any chardev to be a tcp client. I never do that though
>>> as I find it much more convenient to configure it as server.
>>
>> Perhaps thats because chardev clients are nearly useless right now
>> because they just die if the connection drops...
>
> Which is why drops/missing server should be a QMP event + action, same
> as other triggers like disk full and watchdog trigger.

So write the code then. I neither want nor care about that feature, so 
why should I write it?

> I do not want my guests to continue running if they are configured to
> depend on Qemu entropy and it's not available.

Realistically though, causes of EGD dissapearing...

1) the daemon dies
2) the daemon is replaced

in the case of 1) then potentially the host, and *every single* guest 
will run out of entropy. You only need one flashing red light, and the 
host can tell you that as well as any of the guests.

Entropy starvation doesnt usually lead to the catastrophic failure you 
describe - 99.9999% of linux machines have no entropy source configured 
and they get along just fine - even with process address space 
randomisation enabled.

In the case of 2) then the downtime is so short that a warning would be 
inappropriate, and the sysadmin would be *right there* anyway.

>> Or are you suggesting that we create another type of chardev, thats
>> nearly like a socket, but speaks egd and can reconnect? That seems
>> hideous to me.
>
> Why hideous?

Because automatic reconection should not apply to only one type of 
socket, but all. Why deliberately cripple a feature and make it specific 
when one does not have to?

> An egd chardev is a good thing because you can then trivially
> use it as a random byte source for virtio-serial, isa-serial,
> pci-serial, custom-soc-serial, debug-port even :-), and anything
> else which might want random bytes as Gerd said.

Yes, but qemu (AFAICT) does not support "line disciplines" so we can 
either have

chrdev_egd+reconnect  ->  virtio-* backend

or

chrdev_socket+reconnect -> virtio-rng+egd backend


IOW, we can either have generic reconnect support, or generic egd 
support, but not both.

Ideally, we'd have line disciplines and it'd be more like this:

chrdev_socket+reconnect -> egd ldisc -> virtio-* backend

So, given that we dont have line disciplines (and I'm not about to write 
more code that is just going to get squabbled over for months) that 
leaves us with a choice to make.

I personally say that generic EGD support is less useful than generic 
socket reconnect support, since at a pinch, and as others have pointed 
out, EGD can be implemented externally to qemu.

Socket reconnection _cannot_ be implemented externally, and frankly, I 
consider it a bug that qemu basically presents an option (client 
sockets) that once it dies, the user has no way of re-instating other 
than to kill and restart qemu.

> That's way more useful than restricting to virtio-rng, because most
> guests don't support virtio at all, but they can probably all take
> entropy from a serial-like device.

a) The kind of guest that cant do virtio is damn unlikely to be in use 
in a server-farm, and

b) Nothing stops someone running an egd->serial converter on the host in 
order to feed a serial-like device.

> Similarly the ability to connect to /dev/urandom directly, with the
> rate-limiting but no auto-reconnection, looking like a chardev in
> the same way, would make sense.  Reconnection is not needed in this
> case - missing device should be an error at startup.

My current code will happily read entropy from a file, a char device or 
a socket. It can *also* speak EGD on bidirectional connections like sockets.

> Your idea for an 'egd line discipline' would need to look exactly like
> a chardev internally

Well of course it would. Thats what line disciplines are supposed to do. 
(look at their analogue in the linux tty code)

> In which case it's quite natural to expose the options as a
> user-visible chardev 'egd', defined to return random bytes on input
> and ignore output, which takes all the same options as 'socket' and
> actually uses a 'socket' chardev (passing along the options).

Unless I'm missing something, qemu cannot chain multiple chrdevs 
together. Which means that the hypothetical egd chardev would have to 
duplicate 100% of the socket chrdev logic.

> I think rate-limiting is more generically useful as a 'line
> discipline'-like feature, to work with any chardev type.  But it
> should then have properties governing incoming and outgoing rate
> limiting separately, which won't get much testing for the only
> imminent user which is input-only.

but again, qemu doesn't *have* line disciplines.

-Ian