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

[Anthony Liguori]

On 11/17/2011 02:59 AM, Ayal Baron wrote:
> ----- 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.

No, the way we plan on doing this is having a guest agent schema 
(qapi-schema-guest.json) that we can use to (1) white list valid operations and 
(2) decode and re-encode operations.

(1) let's us validate that guest state isn't escaping which keeps migration safe

(2) let's us scrub any potentially malicious input from the guest before we hand 
it off to the management tool.

Otherwise, we don't get in the middle and don't really care what the verbs are.

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

I'm not sure I understand what you're suggesting.

Here's another way to think of this.  In a typical enterprise environment, you 
would secure your network infrastructure using isolated zones.  You may have a 
red zone (guest networking), a yellow zone (management network), and a green 
zone (broader intranet).  The zones are physically separate with very few things 
that exist on two zones.

You pay special attention to anything that crosses zones and try to minimize 
them as much as possible.  You never allow something to live on more than two zones.

The guest is the red zone and the rest of the host environment is the yellow 
zone.  QEMU bridges between the red and yellow zone.  That is fundamentally its 
job in the stack.

Other than the guest agent, VDSM lives purely in the yellow zone.  In fact, VDSM 
bridges from the yellow zone to the green zone (broader management infrastructure).

It may be easier to skip QEMU and have VDSM also stride into the red zone.  It's 
always easier to cross zones.  But it's not good security practice.  There is 
tremendous value in having clean security layers.

Regards,

Anthony Liguori