All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Molton <ian.molton@collabora.co.uk>
To: Jamie Lokier <jamie@shareable.org>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Socket reconnection.
Date: Mon, 07 Dec 2009 09:29:19 +0000	[thread overview]
Message-ID: <4B1CCAEF.8070208@collabora.co.uk> (raw)
In-Reply-To: <20091207022934.GC1021@shareable.org>

Jamie Lokier wrote:
> Ian Molton wrote:
>>>> Besides, not all entropy comes from /dev/random.

> Those arguments are weak.

No worse than the counterarguments.

If nothing else, qemu is a useful tool for testing kernel subsystems and
in fact the virtio code triggered and caused to be fixed a number of
bugs / flaws in the kernels hw random core and virtio driver. That alone
I think shows it has value.

> 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.

I have no idea - too much crack? :-)

one might run rngd, or use /dev/hwrng directly, but I cant see why you'd
want to run egd on it.

> 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.

Im not proposing that. I'm saying the HOST machine would be getting
entropy from egd, directly into qemu. That entropy comes out of the
guests /dev/hwrng.

I can see value there too - the hosts /dev/random pool cannot be
compromised by the guest OS. But nothings stopping you specifying
/dev/random as qemus entropy source.

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

I have no system here with that hardware either - however I had access
(via an ssh tunnel) to another machine that did have it, and could feed
qemu direct from that stream. qemu spoke egd over the tunnel, and fed
the guests /dev/hwrng. The guest was passing FIPS tests at the same
speed the hardware could produce entropy. Are you suggesting that I
should have fed the hosts entropy pool (via RNGD) and then fed that to
the guest ia qemu? why?

>> Since we need this on hosts without /dev/random anyway, I dont see why
>> we would need to deliberately cripple qemu on linux hosts...
>
> The lack of option is crippling qemu on linux hosts which don't run egd.

Sorry, what?

> 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

apt-get install rng-tools

>     CentOS 4.0            - no egd running, no rngd running
>     RHEL 4.0              - no egd running, no rngd running

Presumably one can install rngd easily on these systems too.

I have a machine here that is not running X - does that make X worthless?

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

No, because it is just as happy reading raw data from /dev/random as it
it to speak EGD protocol over a socket. Have you actually tried the patch?

-Ian

  reply	other threads:[~2009-12-07  9:30 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-26  0:31 [Qemu-devel] Socket reconnection Ian Molton
2009-11-26  9:21 ` Gerd Hoffmann
2009-11-27  9:01 ` Jamie Lokier
2009-12-01 11:55   ` Ian Molton
2009-12-06 14:32     ` Jamie Lokier
2009-12-06 16:33       ` Ian Molton
2009-12-07  2:29         ` Jamie Lokier
2009-12-07  9:29           ` Ian Molton [this message]
2009-11-30 17:18 ` Anthony Liguori
2009-12-01 11:54   ` Ian Molton
2009-12-01 14:38     ` Krumme, Chris
2009-12-01 18:29       ` Ian Molton
2009-12-01 18:54       ` Anthony Liguori
2009-12-02 10:40         ` Ian Molton
2009-12-02 12:04           ` [Qemu-devel] " Jan Kiszka
2009-12-02 19:56           ` [Qemu-devel] " Anthony Liguori
2009-12-02 22:35           ` Krumme, Chris
2009-12-03 10:04             ` Ian Molton
2009-12-03 10:23               ` Kevin Wolf
2009-12-03 14:22               ` Anthony Liguori
2009-12-03 18:37                 ` [Qemu-devel] [PATCH]Socket reconnection Ian Molton
2009-12-05 22:03                   ` Ian Molton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B1CCAEF.8070208@collabora.co.uk \
    --to=ian.molton@collabora.co.uk \
    --cc=jamie@shareable.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.