From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: Revokable Grants Design (draft B) Date: Thu, 28 Jan 2016 16:53:57 +0000 Message-ID: <56AA47A5.2020405@citrix.com> References: <56A65948.6000200@citrix.com> <56AA43E902000078000CC1B4@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aOppb-0006bT-W1 for xen-devel@lists.xenproject.org; Thu, 28 Jan 2016 16:54:04 +0000 In-Reply-To: <56AA43E902000078000CC1B4@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , David Vrabel Cc: xen-devel , Daniel De Graaf List-Id: xen-devel@lists.xenproject.org On 28/01/16 15:38, Jan Beulich wrote: >>>> On 25.01.16 at 18:20, wrote: >> High Level Design >> ================= >> >> A revokable grant is indicated by an additional flag in the grant >> table entry. A domain may only map such a grant using a new sub-op >> (`GNTABOP_map_revokable`) and must supply a local GFN. >> >> When the granting domain wishes to revoke a grant it: >> >> 1. Removes access from the grant, but does not make the grant >> available for other uses. The prevents any new grant map or copies >> from starting. >> >> 2. Makes a `GNTTABOP_revoke` hypercall if the grant is in use (e.g., >> mapped). The hypervisor atomically switches any mappings of the >> grant to the local GFN supplied when it was mapped. The hypervisor >> will also wait for any in-progress grant copies to complete. > > What about transfers? Presumably no-one uses them these days, > but they're part of the interface and hence need to be considered. > (But I guess accounting for them here is as simple as naming them > alongside copies. Or wait, "Low Level Design" seems to suggest you > simply disallow transfers for them.) Transfers would be disallowed. Or rather, only map_revokable and copy are allowed. >> Low Level Design >> ================ >> >> Grant Table Entry >> ----------------- >> >> A new `GTF_revokable` flag is added. A grant reference with this bit >> set may only be mapped with `GNTTABOP_map_revokable` or copied with >> `GNTTABOP_grant_copy` (subject to the usual permission checks). >> >> Attempts to use `GNTTABOP_map_grant_ref` with such a reference must >> fail with -EACCESS. Without a replacement page, revoking such a >> mapping would require clearing the mapping which would allow the >> granter to trigger faults in the mapper. > > What about the inverse (GNTTABOP_map_revokable on non- > revokable grant)? Failure, or some kind of indication to the caller that > the GFN is not going to be used? I would disallow it I think. I can't think of a case where this would be useful. >> ### `GNTTABOP_revoke` >> >> struct gnttab_revoke { >> grant_ref_t ref; >> }; >> >> -------------------------------------------------------------------- >> Field Purpose >> ----- ------------------------------------------------------ >> `ref` The grant reference whose access is being revoked. >> -------------------------------------------------------------------- >> >> The caller must first remove access from the grant reference to >> prevent any new grant maps or copies from starting. > > Is the hypervisor expected to check this, and fail if it's not the > case? No. Because Xen cannot guard against the guest permitting access (e.g., by setting GTF_permit_access again or via another grant reference) while the revoke hypercall is in progress. Or possibly: Yes, Because, although this won't catch all incorrect behaviour of the guest, it will catch the most obvious mistake. I can't decide on which is best. David