Re: [Xen-devel] Revokable Grants Design (draft B)

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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