Re: [Qemu-devel] [RFC][PATCH v6 00/23] virtagent: host/guest RPC communication agent

[Jes Sorensen <Jes.Sorensen@redhat.com>]

On 02/17/11 15:39, Michael Roth wrote:
> On 02/17/2011 02:26 AM, Jes Sorensen wrote:
>> On 02/16/11 18:22, Michael Roth wrote:
>> worry is that we are adding a lot of complexity into QEMU on the host
>> side which is going to be difficult to audit, especially with things
>> like the HTML and XML processing. If we separated host side processing
>> into a separate command, we could better protect ourselves against a
>> situation where a rogue guest could kill QEMU and possibly exploit it on
>> the host side. I think we should seriously look at moving the agent
>> processing code out of main QEMU and into a standalone command, maybe
>> qemu-va-host or something like that.
> 
> I don't think the problem is really so fundamental...if you saw a
> host-side crash it's most likely a bug/sloppy error-handling in
> virtagent. Malformed xml (from version mismatches, transports errors,
> etc) shouldn't crash xmlrpc-c... it's using a libxml parser that just
> returns an error on unexpected xml...we just need to make sure we handle
> errors appropriately.

Hi Michael,

It may not be so fundamental, but it still makes me wary. XMLRPC
handling is quite high level and introduces the potential of errors that
are outside of our direct control. Personally I don't see the big
benefit of having virtagent terminate in QEMU, if anything it actually
makes me wary. I would quite like to see the monitor moved out of QEMU
as well and into it's own process - the simpler we make QEMU in this
regard, the more secure it will be to run. Using either a fork()
approach or simply a separate process that connects to the QEMU process
seems a very reasonable approach IMHO.

> Can you provide some details on what you ran and what the error message
> was?

It's a bit tricky, I was running a my tests over VNC on a remote system
(think trans-Atlantic latency) while having 10 people watch while I
typed the commands. It seemed that pretty much every agent command was
causing it, including ping, but unfortunately I didn't save the backtrace.

Cheers,
Jes