Re: [Xen-devel] [PATCH v2 3/4] xen/arm: introduce GNTTABOP_cache_flush

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

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@xxxxxxxxxxxxx>
> >> [...]
> >>> --- 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.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel