[Qemu-devel] converging around a single guest agent

[Ayal Baron]

----- Original Message -----
> 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.

Exposing higher level management interfaces means that qemu would have to do policy.
I have no problem with this, but note that this is counter to what you've been advocating to up to now (e.g. high watermark event for disks).

Also, you would still have to have low level interfaces to accomplish things that qemu has not implemented yet or is not interested in implementing (the use case is too narrow).

> 
> 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

So are you suggesting that when a user reads a file you would automatically encode the contents?

> 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

No, vdsm runs as user vdsm.  Operations that need root privileges are in a separate process with root privileges and this process exposes a limited API which vdsm is allowed to invoke.

> 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
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/vdsm-devel
>