[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Revokable Grants Design (draft B)
>>> On 28.01.16 at 17:53, <david.vrabel@xxxxxxxxxx> wrote: > On 28/01/16 15:38, Jan Beulich wrote: >>>>> On 25.01.16 at 18:20, <david.vrabel@xxxxxxxxxx> wrote: >>> 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. It would allow mapping code to always use the new op, without needing to be told by the other side. >>> ### `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. I lean towards the latter. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |