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
to the host. QEMU expose an emulated AHCI controller and turns that into VFS
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
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.
vdsm-devel mailing list