Re: [Xen-devel] default XSM policy for PCI passthrough for unlabeled resources.

[anshul makkar <anshul.makkar@xxxxxxxxxx>]

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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel