Re: [Xen-devel] [PATCH v3 20/24] xen/passthrough: Extend XEN_DOMCTL_assign_device to support DT device

[Julien Grall <julien.grall@xxxxxxxxxx>]

Hi Daniel,

On 10/03/2015 23:39, Daniel De Graaf wrote:
> On 03/10/2015 07:07 PM, Julien Grall wrote:
> > Hi Daniel,
> >
> > On 10/03/2015 22:45, Daniel De Graaf wrote:
> > > > BTW, do you have any pointer on how to write a policy for device/IRQ
> > > > passthrough?
> > > There is a bit of documentation in xsm-flask.txt about device labeling,
> > > which is the hard part of making passthrough work.  Labels can be set
> > > either statically in the security policy (as documented in the section
> > > "Device Labeling") or dynamically using a tool like flask-label-pci
> > > as documented in "Resource Policy".  Once that is done, then rules to
> > > allow the passthrough operation can be added, similar to the example
> > > resource nic_dev_t in xen.te.
> > I tried to follow xsm-flask.txt and uncomment one of the pirqcon line
> > in the xsm policy.
> >
> > But I got the following error:
> >
> > policy/modules/xen/xen.te:199:ERROR 'syntax error' at token 'pirqcon'
> > on line 1986:
> > pirqcon 33 system_u:object_r:nic_dev_t
> >
> > Did I miss anything?
> No, this is an error in either the policy or the parser in checkpolicy.
> The parser in checkpolicy is rather inflexible, and it currently requires
> that the device labels be specified at the end of the policy.conf instead
> of in the middle (as they are now).  You should add the commented out
> lines to the end of tools/flask/policy/policy/initial_sids for now; I will
> be sending a patch to move them to another file tomorrow.
It's working now. Thanks!

> > > In order to do static labeling for device passthrough, the nodes in a
> > > device tree need a 32-bit numeric identifier.  IO memory uses the MFN,
> > > PCI devices use SBDF, and IRQs and x86 legacy IOs just use the number.
> > Why it's restricted to an integer? Would it be possible to use a
> > string as it's done for the sid?
> The sid is not actually represented as a string internally: it is mapped
> into a set of integers for the user/role/type and MLS range.
I gave a look to the checkpolicy code and the ocontext can store pretty 
much anything.
Currently for IOMEM, 2 32-bit number is stored to describe the range.

AFAIU, in order to support DT device, I will have to update checkpolicy 
for adding a new token (smth like dtdevicecon). So I don't see why I 
couldn't use a string for purpose.
Or maybe you had in mind to reuse pcidevicecon?

Regards,

--
Julien Grall

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