[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



On 03/10/2015 12:52 PM, Julien Grall wrote:
Hi Daniel,

On 23/02/15 16:25, Daniel De Graaf wrote:
On 02/20/2015 12:17 PM, Ian Campbell wrote:
On Tue, 2015-01-13 at 14:25 +0000, Julien Grall wrote:
TODO: Update the commit message

A device node is described by a path. It will be used to retrieved the
node in the device tree and assign the related device to the domain.

Only device protected by an IOMMU can be assigned to a guest.

Signed-off-by: Julien Grall <julien.grall@xxxxxxxxxx>
Cc: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
Cc: Wei Liu <wei.liu2@xxxxxxxxxx>
Cc: Jan Beulich <jbeulich@xxxxxxxx>

---
      Changes in v2:
          - Use a different number for XEN_DOMCTL_assign_dt_device
---
   tools/libxc/include/xenctrl.h         | 10 ++++
   tools/libxc/xc_domain.c               | 95
++++++++++++++++++++++++++++++++--

These bits all look fine.

+int iommu_do_dt_domctl(struct xen_domctl *domctl, struct domain *d,
+                       XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
+{
+    int ret;
+    struct dt_device_node *dev;
+
+    /* TODO: How to deal with XSM? */

Adding Daniel.

It seems the PCI ones are protected by
          xsm_test_assign_device(XSM_HOOK,
domctl->u.assign_device.machine_sbdf);

So it seem that either this needs to become "test_assign_pci_device" and
a similar "test_assign_dt_device" needs to be added and plumbed through
or it needs to grow a type parameter and take the union for the
identifier.

Either would work, but a distinct hook seems simpler to me, especially as
the call sites are distinct and the hook would process them differently.

Sounds good.

The code to apply an XSM context to a DT node would need consideration
too I suppose?

This may require a bit more thought.  At first glance, the dt_phandle
field seems to be an identifier that could be used by FLASK to identify a
device using an ocontext lookup.  Labeling would then be done in the same
way as PCI devices and x86 legacy I/O ports.

We don't always have a dt_phandle in hand. They are mostly used for
referencing a node within another (such as IOMMU, interrupt
controller...). Also, the value is controlled by the compiler.

AFAICT, the only unique value we have in hand is the path of the device.

OK. I was hoping that there would be a unique numeric identifier.  If
there is not, it may be necessary to either create one or to add a new
field to device nodes (like the one for event channels) so that they
can be labeled.

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.

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.

If device tree nodes can be labeled in this way, they could be added
as another resource type in the policy.  If not, then the label of a
device node will need to be set at boot using the XSM hypercalls;
this label would be stored in a security field added to device tree
nodes.

--
Daniel De Graaf
National Security Agency

_______________________________________________
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®.