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

[Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>]

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