From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:52946) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RR3BF-0007Y3-OY for qemu-devel@nongnu.org; Thu, 17 Nov 2011 09:43:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RR3BA-0005Hg-59 for qemu-devel@nongnu.org; Thu, 17 Nov 2011 09:43:09 -0500 Received: from mail-iy0-f173.google.com ([209.85.210.173]:52941) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RR3BA-0005HU-0M for qemu-devel@nongnu.org; Thu, 17 Nov 2011 09:43:04 -0500 Received: by iakk32 with SMTP id k32so2457991iak.4 for ; Thu, 17 Nov 2011 06:43:03 -0800 (PST) Message-ID: <4EC51D73.9050901@codemonkey.ws> Date: Thu, 17 Nov 2011 08:42:59 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <030b182c-2851-40e5-b0e8-682725258fac@zmail07.collab.prod.int.phx2.redhat.com> In-Reply-To: <030b182c-2851-40e5-b0e8-682725258fac@zmail07.collab.prod.int.phx2.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] converging around a single guest agent List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ayal Baron Cc: Barak Azulay , Gal Hammer , vdsm-devel@lists.fedorahosted.org, qemu-devel@nongnu.org, Michael Roth , arch@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