Re: [Xen-devel] [RFC PATCH V3 05/12] xen: Introduce vm_event

[Tamas K Lengyel <tamas.lengyel@xxxxxxxxxxxx>]

On Fri, Jan 30, 2015 at 6:25 PM, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> wrote:
> On 01/29/2015 04:46 PM, Tamas K Lengyel wrote:
>>
>> To make it easier to review the renaming process of mem_event -> vm_event,
>> the process is broken into three pieces, of which this patch is the first.
>> In this patch the vm_event subsystem is introduced and hooked into the
>> build
>> process, but it is not yet used anywhere.
>>
>> Signed-off-by: Tamas K Lengyel <tamas.lengyel@xxxxxxxxxxxx>
>
>
> [...]
>>
>> diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
>> index f20e89c..d6d403a 100644
>> --- a/xen/include/xsm/dummy.h
>> +++ b/xen/include/xsm/dummy.h
>> @@ -525,6 +525,18 @@ static XSM_INLINE int
>> xsm_mem_event_op(XSM_DEFAULT_ARG struct domain *d, int op)
>>       XSM_ASSERT_ACTION(XSM_DM_PRIV);
>>       return xsm_default_action(action, current->domain, d);
>>   }
>> +
>> +static XSM_INLINE int xsm_vm_event_control(XSM_DEFAULT_ARG struct domain
>> *d, int mode, int op)
>> +{
>> +    XSM_ASSERT_ACTION(XSM_PRIV);
>> +    return xsm_default_action(action, current->domain, d);
>> +}
>> +
>> +static XSM_INLINE int xsm_vm_event_op(XSM_DEFAULT_ARG struct domain *d,
>> int op)
>> +{
>> +    XSM_ASSERT_ACTION(XSM_DM_PRIV);
>> +    return xsm_default_action(action, current->domain, d);
>> +}
>>   #endif
>>
> [...]
>>
>> diff --git a/xen/xsm/flask/policy/access_vectors
>> b/xen/xsm/flask/policy/access_vectors
>> index 1da9f63..a4241b5 100644
>> --- a/xen/xsm/flask/policy/access_vectors
>> +++ b/xen/xsm/flask/policy/access_vectors
>> @@ -250,6 +250,7 @@ class hvm
>>       hvmctl
>>   # XEN_DOMCTL_set_access_required
>>       mem_event
>> +    vm_event
>>   # XEN_DOMCTL_mem_sharing_op and XENMEM_sharing_op_{share,add_physmap}
>> with:
>>   #  source = the domain making the hypercall
>>   #  target = domain whose memory is being shared
>>
>
> This implies that device model domains should be allowed to use the
> operations
> covered by xsm_vm_event_op but not those covered by xsm_vm_event_control.
> If this is how the eventual operations are intended to be used, the FLASK
> permissions also need to be split so that a similar distinction can be made
> in
> the policy.
>
> After looking at the later patches in this series, this appears to be a flaw
> in
> the existing FLASK hooks that got copied over.  While it is still useful to
> fix,
> it  may be better to make the split in a separate patch from the renames.
> Now
> that VM events apply to more than just HVM domains, it may be useful to move
> the new permission(s) from class hvm to either domain2 or mmu.
>
> --
> Daniel De Graaf
> National Security Agency

Moving it to domain2 would make sense to me. The namings seem to be
pretty poor so I have a hard time understanding why xsm_vm_event_op
and xsm_vm_event_control differ when it comes to device model domains.
The event_op corresponds to memops for access, paging and sharing
while event_control for the domctl that enables/disables the rings. So
yes, I think splitting the name for these separating things would make
sense to clarify what they represent but whether that restriction on
device model domains was intentional I'm not sure about.

Tamas

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