Re: default XSM policy for PCI passthrough for unlabeled resources.

[anshul makkar <anshul.makkar@citrix.com>]

On 07/07/16 16:36, Daniel De Graaf wrote:
> On 07/06/2016 12:19 PM, anshul makkar wrote:
>> On 06/07/16 16:59, Daniel De Graaf wrote:
>>> On 07/06/2016 11:34 AM, anshul makkar wrote:
>>>> Hi,
>>>>
>>>>
>>>> It allows the resource to be added and removed by the source domain to
>>>> target domain, but its use by target domain is blocked.
>>>
>>> This rule only mandates the use of resource_type for resource types.  If
>>> you are creating a new resource type, follow the example in nic_dev.te.
>> Agreed, but inherently it means that "use" of any unlabeled resource
>> be it irq, ioport or iomem or nic_dev is restricted.
>
> Restricted how?  The fallback types have the resource_type attribute.
Restricted if they are unlabeled.
>
> Neverallow rules are actually not present in the binary policy; they act as
> compile-time assertions in the policy build.
>
Fine.
>>>
>>>> The resource can be used only if it has been labeled using
>>>> flask-label-pci command which needs to be rerun after every boot and
>>>> after every policy reload.
>>>
>>>
>>> Try adding a module with the following rules, which should allow domU to
>>> use unlabeled devices:
>>>
>>> use_device(domU_t, irq_t)
>>> use_device(domU_t, ioport_t)
>>> use_device(domU_t, iomem_t)
>>> use_device(domU_t, device_t)
>> Yes, it does work , but I have added these in delegate_device to make
>> it restrict to the case where there is delegation.
>
> This prevents using delegate_devices without allowing access to unlabeled
> devices.  If you think this should be a macro, I would suggest making a new
> one named something like "delegate_unlabeled_devices".
>

Agreed. That's a better approach.
I believe this macro can make the default policy more flexible and 
useful for more general audience, so it should be there in the policy. I 
can submit patch for the same. Your thoughts ?

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