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

[Jamie Lokier]

Ian Molton wrote:
> Jamie Lokier wrote:
> > First of all: Why are your egd daemons with open connections dying
> > anyway?  Buggy egd?
> 
> No, they aren't buggy. but occasionally, the sysadmin of said server
> farms may want to, you know, update the daemon?

Many daemons don't kill active connections on upgrade.  For example
sshd, telnetd, ftpd, rsyncd...  Only new connections get the new daemon.

But let's approach this from a different angle:

What do _other_ long-lived EGD clients do?  Is it:

   1. When egd is upgraded, the clients break.
   3. Active connections aren't killed on egd upgrade.
   2. They keep trying to reconnect, as you've implemented in qemu.
   4. Whenever they want entropy, they're expected to open a
      connection, request what they want, read it, and close.  Each time.

Whatever other long-lived clients do, that's probably best for qemu
too.

4 is interesting because it's an alternative approach to rate-limiting
the byte stream: Instead, fetch a batch of bytes in a single
open/read/close transaction when needed.  Rate-limit _that_, and you
don't need separate reconnection code.

So I trying checking if egd kills connections when upgraded, and found...

No 'egd' package for my Debian and Ubuntu systems, nor anything which
looks obvious.  There are several other approaches to gathering
entropy from hardware sources, for example rng-tools, haveged, ekeyd, and
ekeyd-egd-linux (aha... it's a client).

All of those have in common: they fetch entropy from something, and
write it to the kernel's /dev/random pool.  Applications are expected
to read from that pool.

In particular, if you do have a hardware or network EGD entropy
source, you can run ekeyd-egd-linux which is an EGD client, which
transfers from EGD -> the kernel, so that applications can read from
/dev/random.

That means, on Debian & Ubuntu Linux at least, there is no need for
applications to talk EGD protocol themselves, even to get network or
hardware entropy - it's better left to egd-linux, rng-tools etc. to
manage.

But the situation is no doubt different on non-Linux hosts.

By the way, ekeyd-egd-linux is a bit thoughtful: For example it has a
"shannons-per-byte" option, and it doesn't drain the EGD server at all
when the local pool is sufficiently full.

Does your EGD client + virtio-rng support do that - avoid draining the
source when the guest's pool is full enough?

> > If guests need a _reliable_ source of data for security, silently not
> > complaining when it's gone away and hoping it comes back isn't good
> > enough.
> 
> Why? its not like the guest:
> 
> a) Has a choice in the matter
> b) Would carry on without the entropy (it knows it has no entropy)

Because one might prefer a big red light, a halted machine removed
from the cluster which can resume its work when ready, and an email to
warn you that the machine isn't able to operate normally _without_
having to configure each guest's email, rather than a working machine
with increasing numbers of stuck crypto processes waiting on
/dev/random which runs out of memory and after getting into swap hell,
you have to reboot it, losing the other work that it was in the
middle of doing.

Well, you personally might not prefer that.  But that's why we
separate policy from mechanism...

> > But then it would need to sync with the guest on reconnection, so that
> > the guest can restart whatever protocol it's using over the byte
> > stream.
> 
> Er, why? we're not talking about port forwarding here, we're talking
> about emulation of device hardware.

virtio-serial isn't emulating a normal serial port.  It supports apps
like "send machine status blobs regularly", without having to be
robust against half a blob being delivered.

You can design packets so that doesn't matter, but virtio-serial
supports not needing to do that, making the apps simpler.

> > I don't think it'll happen.  I think egd is a rather unusual
> > If another backend ever needs it, it's easy to move code around.
> 
> *bangs head on wall*
> 
> That was the exact same argument I made about the rate limiting code.
> Why is that apparently only valid if its not me that says it?

Because you're talking to multiple people who hold different opinions,
and opinions change as more is learned and thought about.  It's
iterative, and I, for one, am not in a position to make merging
decisions, only give my view on it.  Can't speak for the others.

> > I'm not convinced there's a need for it even for egd.
> 
> So what? I'm not convinced theres a need for about 90% of whats out
> there,

Ah, that's not quite what I meant.  I meant I wasn't convinced it is
needed for egd, not I don't think anyone should use egd.  (But now I
see that egd-linux has a "reconnect time" option, perhaps reconnecting
_is_ de facto part of EGD protocol.)

But now that we've confirmed that on Debian & Ubuntu, all hardware
entropy sources are injected into /dev/random by userspace daemons
rather than serving EGD protocol, and if you do have an EGD server you
can run egd-linux and apps can read /dev/random, and egd-linux won't
drain the EGD server unnecessarily... are you sure EGD support is
appropriate?  Is it different on, say, Fedora?  Or are you thinking of
other hosts?

-- Jamie