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

[anshul makkar <anshul.makkar@xxxxxxxxxx>]

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