[Qemu-devel] converging around a single guest agent

[Carl Trieloff]

forwarding and added to subscription list.

Carl.


On 11/17/2011 09:43 AM, arch-bounces at ovirt.org wrote:
> Re: [Qemu-devel] converging around a single guest agent.eml
>
> Subject:
> Re: [Qemu-devel] converging around a single guest agent
> From:
> Anthony Liguori <anthony at codemonkey.ws>
> Date:
> 11/17/2011 09:42 AM
>
> To:
> Ayal Baron <abaron at redhat.com>
> CC:
> Barak Azulay <bazulay at redhat.com>, Michael Roth
> <mdroth at linux.vnet.ibm.com>, Gal Hammer <ghammer at redhat.com>,
> vdsm-devel at lists.fedorahosted.org, qemu-devel at nongnu.org, arch at ovirt.org
>
>
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20111117/1b7c04ac/attachment.html>