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

[Daniel De Graaf <dgdegra@tycho.nsa.gov>]

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.

Neverallow rules are actually not present in the binary policy; they act as
compile-time assertions in the policy build.

>>
>>> 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.
>>
>> Yes; this gives the most control over what resources can be delegated.
>> Policy reloads are supposed to be rare (on a production system) and you
>> already need special boot scripts (or parameters) to set up the device
>> for passthrough, so this can be added there.  However, I agree this can
>> be more work than a "default" FLASK policy should require.
>>
>> 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".

-- 
Daniel De Graaf
National Security Agency

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