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

From: anshul makkar <anshul.makkar@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com, cardoe@cardoe.com
Subject: Re: default XSM policy for PCI passthrough for unlabeled resources.
Date: Wed, 6 Jul 2016 17:19:15 +0100	[thread overview]
Message-ID: <577D2F83.7000103@citrix.com> (raw)
In-Reply-To: <6be3e7fc-f3c6-8c9c-39fb-0c1c1d9a4389@tycho.nsa.gov>

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.
>
>> 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.
>
> If this works, that module could be added to the default policy.
>
>> Given that what we ship is just a sample default policy for reference
>> which is expected to be permissive in most of the scenarios so that it
>> doesn't affect the basic functionalities, is this "neverallow" rule
>> needed ?
>>
>> Thanks
>> Anshul Makkar
>
> The neverallow rules are just there to ensure that the attributes are
> being used correctly.
>
Anshul

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