qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Socket reconnection.


From: Ian Molton
Subject: Re: [Qemu-devel] Socket reconnection.
Date: Mon, 07 Dec 2009 09:29:19 +0000
User-agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090707)

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 via email to

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