qemu-devel
[Top][All Lists]
Advanced

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

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


From: Ian Molton
Subject: Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG
Date: Sat, 24 Apr 2010 10:16:57 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100411 Icedove/3.0.4

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




reply via email to

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