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