Re: [Qemu-devel] Socket reconnection.

[Jamie Lokier]

Ian Molton wrote:
> >> Besides, not all entropy comes from /dev/random.
> > 
> > On a Linux host, why isn't rngd simply injecting it's entropy into
> > /dev/random where it would be more convenient to access?  (No need for
> > socket reconnection code, for example).
> 
> Who knows? lack of privs, an admin who only uses egd, a machine which is
> being fed entropy by egd via a tunnel. User doesnt trust /dev/random,
> /dev/random known to be failing FIPS tests on a shared machine - there
> could be any number of reasons. In our case, entropy is comming from
> hardware via egd, to be used in the guest VMs. why feed it into RNGD,
> then the hosts entropy pool, THEN the guests - just feed them directly.
> the egd daemon in this case also offers load balancing to all consumers
> of entropy.

Those arguments are weak because they also apply the other way: an
admin who only uses /dev/random (got lots of those), a machine which
is being fed entropy into /dev/random via a tunnel (been there), user
doesn't trust egd (why should I trust it more than the kernel?
userspace is more easily corrupted - and with a socket, it might not
even be egd running), etc.

I grant you there are advantages sometimes, but also disadvantages.
Why would I run egd on a guest VM running an embedded system with 16MB
RAM, where every process is precious, for example?  But those systems
need entropy too.

As for why feed it "directly" via hardware -> egd -> guest", the
reason surely is because most clients read /dev/random or
/dev/urandom, so entropy that isn't injected into /dev/random is wasted.

Anyway, I've just read the rngd manual, and it does inject it's
entropy into /dev/random so that's the end of that discussion :-)

But the main issue is below.  On all host systems I have access to,
there is _no_ entropy available from egd/rngd...

> Since we need this on hosts without /dev/random anyway, I dont see why
> we would need to deliberately cripple qemu on linux hosts...

Since nobody has asked you to cripple anything, that is irrelevant.
Options don't cripple.

The lack of option is crippling qemu on linux hosts which don't run egd.

Which hosts are those?  Well, I've just checked five live systems,
four servers and one laptop, running:

    Ubuntu 9.10 (Karmic)  - no egd running, no rngd running
    Ubuntu 9.04 (Jaunty)  - no egd running, no rngd running
    Debian 4.0 (Etch)     - no egd running, no rngd running
    CentOS 4.0            - no egd running, no rngd running
    RHEL 4.0              - no egd running, no rngd running

So if I understand right, the virtio-rng host driver won't work on any
host system I have access to?  Is that correct?

Btw, /dev/random is available on virtually every host - Linux,
Solaris, FreeBSD, Mac OS X, NetBSD, OpenBSD, Tru64, HP-UX, AIX, and
there's even a similar device for Windows :-)

I grant you the egd/rngd entropy is preferable on a system that's
running it.  It is much more careful.  (Let's ignore this in rngd's
man page: "Do not do that unless you trust rngd's source of random
data").  So a good default would be to use the egd/rngd socket when
available, and fall back to /dev/random or even /dev/urandom (at user
request) when not.

My tests show that egd/rngd are not running on any host system I have
access to - and that's quite a diverse range of Linuxes.  It would
have to be run specially, which sounds problematic as qemu would be
the only process using it.

-- Jamie