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
