From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [PATCH v2 3/4] xen/arm: introduce
 GNTTABOP_cache_flush
Date: Wed, 8 Oct 2014 14:01:25 +0100
Message-ID: <1412773285.24894.4.camel@citrix.com>
References: <alpine.DEB.2.02.1410031543550.17038@kaball.uk.xensource.com>
	<1412347845-27755-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<5432B382.3040000@citrix.com>
	<alpine.DEB.2.02.1410081248250.17038@kaball.uk.xensource.com>
	<543528C1.9090901@citrix.com>
	<alpine.DEB.2.02.1410081350150.17038@kaball.uk.xensource.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <alpine.DEB.2.02.1410081350150.17038@kaball.uk.xensource.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: julien.grall@citrix.com, xen-devel@lists.xensource.com, David Vrabel <david.vrabel@citrix.com>
List-Id: xen-devel@lists.xenproject.org

On Wed, 2014-10-08 at 13:52 +0100, Stefano Stabellini wrote:
> On Wed, 8 Oct 2014, David Vrabel wrote:
> > On 08/10/14 12:54, Stefano Stabellini wrote:
> > > On Mon, 6 Oct 2014, David Vrabel wrote:
> > >> On 03/10/14 15:50, Stefano Stabellini wrote:
> > >>> Introduce a new hypercall to perform cache maintenance operation on
> > >>> behalf of the guest. The argument is a machine address and a size. The
> > >>> implementation checks that the memory range is owned by the guest or the
> > >>> guest has been granted access to it by another domain.
> > >>>
> > >>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > >> [...]
> > >>> --- a/xen/common/grant_table.c
> > >>> +++ b/xen/common/grant_table.c
> > [...]
> > >>> @@ -2641,6 +2641,79 @@ do_grant_table_op(
> > >>> +
> > >>> +        if ( !grant_map_exists(d, owner->grant_table, mfn) )
> > >>
> > >> Looping over all grant table entries or all maptrack entries looks
> > >> expensive to me.
> > >>
> > >> Perhaps consider allowing suitably privileged domains to
> > >> clean/invalidate any address without having to check if it's been granted.
> > >  
> > > I think that would weaken our security guarantees.
> > 
> > If the domain can map the foreign domain's frames by other means (e.g.,
> > dom0 or a qemu stubdom) then it already has the ability to to
> > clean/invalidate the cache for arbitrary foreign frames.
> 
> True but the ability of mapping any other domain's memory is something
> we could/should get rid of in PV/PVH/ARM only deployments.
> Relying on it for page flushing is not going in the right direction.

Agreed.