|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] converging around a single guest agent |
Date: | Wed, 16 Nov 2011 18:03:11 -0600 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 |
On 11/16/2011 11:53 AM, Barak Azulay wrote:
On Wednesday 16 November 2011 17:28:16 Michael Roth wrote:2) You'd also need a schema, similar to qemu.git/qapi-schema-guest.json, to describe the calls you're proxying. The existing infrastructure in QEMU will handle all the work of marshalling/unmarshalling responses back to the QMP client on the host-side. It's a bit of extra work, but the benefit is unifying the qemu/guest-level management interface into a single place that's easy for QMP/libvirt to consume.The issue is not whether it's possible or not or the amount of efforts need to be done for that to happen, either for qemu-ga or ovirt-guest-agent this work needs to be done. the question is whether all comminication should go through the monitor (hence double proxy) or ... only a subset of the commands that are closly related to hypervisor functionality and separate it from general management-system related actions (e.g. ovirt or any other management system that wants to communicate to the guest).
Yes, all guest interaction should be funnelled through QEMU. QEMU has one job in life--to expose an interface to guests and turn it into something more useful to the host. QEMU expose an emulated AHCI controller and turns that into VFS operations.
Likewise, QEMU should expose a paravirtual "agent" device to a guest, and then turn that into higher level management interfaces.
QEMU's job is to sanitize information from the guest and try to turn that into something that is safer for the broader world to consume. QEMU also deals with isolating state in order to support things like live migration. This ends up being non trivial when it comes to guest agents as it turns out.
When you bypass QEMU and have higher level components talk directly to the guest, you effectively skip through many layers of security and potentially break things like migration by spreading state beyond QEMU. It's of course fixable given enough hacking but it makes for a brittle architecture.
VDSM runs as root, right? That means that a guest driven attack that exploits an issue with guest-agent protocol handling is going to compromise VDSM and gain root access. OTOH, QEMU runs with greatly reduced privileges isolating the effect of such a compromise.
VDSM really shouldn't be talking directly to the guest. libvirt shouldn't be either although it is now because we haven't properly plumbed the guest agent protocol through QMP.
Regards, Anthony Liguori
[Prev in Thread] | Current Thread | [Next in Thread] |