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

[David Vrabel <david.vrabel@xxxxxxxxxx>]

On 28/01/16 15:38, Jan Beulich wrote:
>>>> On 25.01.16 at 18:20, <david.vrabel@xxxxxxxxxx> 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


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