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

[Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>]

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