[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.