Re: [Xen-devel] [PATCH RFC] flask: move policy header sources into hypervisor

[Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>]

On 10/10/2012 04:44 AM, Dario Faggioli wrote:
> Hello Daniel,
> 
> On Tue, 2012-10-09 at 14:31 -0400, Daniel De Graaf wrote: 
>> Ian Campbell wrote:
>> [...]
>>>>> +++ b/xen/xsm/flask/include/av_perm_to_string.h
>>> Also, in that case why is this file checked in?
>>
>> This patch fixes the autogenerated files, but doesn't fully wire them in
>> to things like "make clean" or .{git,hg}ignore. 
>>
> Forgive me for pushing but, while you're here, do you mind taking a look
> and sharing your thoughts about the hunks of the patch touching XSM and
> FLASK? As I said, I've very few experience with that part of Xen, and it
> would be wonderful to know whether what I did looks sane, or I messed
> something up! :-P
> 
> Thanks and Regards,
> Dario
> 

Ah, in my distraction with fixing the autogeneration I neglected to 
finish looking at the original patch. The XSM changes look good except
for a missing implementation of the dummy_nodeaffinity() function in
xen/xsm/dummy.c. However, since the implementation of xsm_nodeaffinity
and xsm_vcpuaffinity are identical, it may be simpler to just merge them
into a common xsm_affinity_domctl hook (as is implemented in
xsm/flask/hooks.c) - in that case, just renaming the existing dummy hook
will suffice.

A more general note on the topic of what XSM permissions to use: 
normally, each domctl has its own permission, and so adding new domctls
would be done by adding a new permission to the access_vectors file
(which is the source of av_perm_to_string.h). However, for this case, it
seems rather unlikely that one would want to allow access to vcpu
affinity and deny node affinity, so using the same permission for both 
accesses is the best solution.

When renaming a permission (such as getvcpuaffinity => getaffinity), the
FLASK policy also needs to be changed - you can normally just grep for
the permission being changed.

The dummy hook would be caught in a compilation with XSM enabled, but I
notice that current xen-unstable will not build due to a patch being
applied out of order (xsm/flask: add domain relabel support requires
rcu_lock_domain_by_any_id which was added in the prior patch). Adding
Keir to CC since he applied the patch.

-- 
Daniel De Graaf
National Security Agency

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