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

[Ian Molton]

Jamie Lokier wrote:
> Ian Molton wrote:
>>> It might make sense to have the reconnect logic in the egd chardev
>>> backend then, thereby obsoleting the socket reconnect patch.
>> Im not sure I agree there... surely there are other things which would
>> benefit from generic socket reconnection support (virtio-rng cant be the
>> only driver that might want to rely on a reliable source of data via a
>> socket in a server-farm type situation?)
> 
> First of all: Why are your egd daemons with open connections dying
> anyway?  Buggy egd?

*AAAAAAAArgh*

Sorry but this is getting to be really annoying now.

I've answered this question at least once (more than that now, I think).

No, they aren't buggy. but occasionally, the sysadmin of said server
farms may want to, you know, update the daemon? This can and *does*
happen, and as explained before, was the actual reason WHY I implemented
reconnect.

> Secondly: why isn't egd death an event reported over QMP, with a
> monitor command to reconnect manually?

how would qemu know the socket was anything special? not everyone uses a
monitor anyway.

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

> It should be an error condition known to management, which
> can halt the guest until egd is fixed or restarts if running without
> entropy isn't acceptable in its policy.

What? why? the guest itself is aware of the out-of-entropy case, just
like real hardware is aware of it. you dont halt every process on the
host just because your entropy source burnt out, the kernel already
handles things because reads on /dev/hwrhg block in this circumstance.

(and anyone using /dev/urandom for crypto directly and without
monitoring real entropy levels is an utter fool).

> Thirdly, which other things do you think would use it?

Anything which reads a socket to feed data to qemu that might
conceiveable have the remote program die / be upgraded / lose its
internet connection. Thats hundreds of possibilities (thousands even).

> Maybe some virtio-serial apps would like it.

Quite possibly.

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

>From the guests point of view, losing the connection is akin to pulling
the wires out of the back of the machine, not ripping out the PCI card.

reconnection in this scenario should (and is in virtio-rng) be handled
at the device layer or higher. (the latter, in the case of
socket-reconnect support).

> In which case, it's better to tell the guest that the connection died,
> and give the guest a way to request a new one when it's ready.

Er. no. I think you've misthought there.

> Reconnecting and resuming in the middle of the byte stram would be bad
> (even for egd protocol?).

Really? because thats what happens from a hardware perspective every
time I yank an ethernet cable etc.

As long as a hook from the reconnect support down to the driver layer is
provided, the drivers can decide how to handle the reconnection.

> Pure /dev/urandom fetching is quite unusual in not
> caring about this, but you shouldn't need to reconnect to that.

EGD only needs minimal support too, as it happens.

But thats not the point. a 'fake' ethernet driver might, for example,
use the reconnect event to signal the guest that the 'physical link' is
up again. The guest would be at liberty to do what it pleased with that
information - just like if someone had yanked a real ethernet lead on
real hardware.

>> Do we really want to re-implement reconnection (and reconnection retry
>> anti-flood limiting) in every single backend?
> 
> 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?

Also can I point to this email from Gerd which I got *before* I wrote
socket-reconnect support. Had I been told it'd never be merged then, I
would never have bothered writing it.

Msg-ID: <address@hidden>

Perhaps now you can see why Im getting so pissed off about all this -
its not like I just wrote this shit and then demanded it be merged. I
sodding well asked first.

> 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, including the entire X86 architecture, which should have died out
immediately after people discovered how crap the 286 was compared to
nearly every other contemporary CPU. But it does exist, because some
people find it useful. Just because you don't like it or you would do it
differently does NOT mean there is a valid reason not to have it.

>  Either egd
> shouldn't be killing open connections (and is buggy if it is), or this
> is normal egd behavior and so it's part of the egd protocol to
> repeatedly reconnect, and therefore can go in the egd client code.

Nope, wrong on both counts (see above).

> Meanwhile, because the egd might not return, it should be reported as
> an error condition over QMP for management to do what it deems
> appropriate.  In which case, management could tell it to reconnect
> when it thinks is a good time, or do other things like switch the
> randomness source to something else, or stop the guest, or warn the
> admin that a guest is running without entropy.

I'm not averse to adding QMP support to the socket reconnect code. Seems
like it might be useful.

However its important to remember that QMP isnt in control of
everything. the EGD daemon is a system-wide thing, handled by the init
scripts and monitors, out of QMPs immediate control. It'd be best to
have both ways of doing things, IMO. (and not everyone uses a monitor).

-Ian