Re: [Qemu-devel] converging around a single guest agent

[Anthony Liguori <anthony@codemonkey.ws>]

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