xsm: policy hooks to require an IOMMU and interrupt remapping

Commit Message

Christopher Clark Aug. 18, 2017, 9:02 p.m. UTC

From: Christopher Clark <[e-mail]>

Isolation of devices passed through to domains usually requires an
active IOMMU. The existing method of requiring an IOMMU is via a Xen
boot parameter ("iommu=force") which will abort boot if an IOMMU is not
available.

More graceful degradation of behaviour when an IOMMU is absent can be
achieved by enabling XSM to perform enforcement of IOMMU requirement.

This patch enables an enforceable XSM policy to specify that an IOMMU is
required for particular domains to access devices and how capable that
IOMMU must be. This allows a Xen system to boot whilst still
ensuring that an IOMMU is active before permitting device use.

Using a XSM policy ensures that the isolation properties remain enforced
even when the large, complex toolstack software changes.

For some hardware platforms interrupt remapping is a strict requirement
for secure isolation. Not all IOMMUs provide interrupt remapping.
The XSM policy can now optionally require interrupt remapping.

The device use hooks now check whether an IOMMU is:
 * Active and securely isolating:
    -- current criteria for this is that interrupt remapping is ok
 * Active but interrupt remapping is not available
 * Not active

This patch also updates the reference XSM policy to use the new
primitives, with policy entries that do not require an active IOMMU.

Signed-off-by: Christopher Clark <[e-mail]>
---
Patch author: Christopher Clark
Copyright belongs to BAE Systems. Written for OpenXT. [OXT-826]
The author is grateful to Daniel De Graaf, Stephen Smalley,
Daniel Smith and Ross Philipson for feedback on earlier revisions
of this patch.

This patch was developed for OpenXT for the 2017 stable-7 release
to ensure that a network interface card cannot be passed through
to the network driver domain unless the IOMMU is active.

Earlier versions of OpenXT had ensured this via logic in the toolstack,
but this behaviour was discovered to have been lost after porting the
upper level of the toolstack to use libxl. This motivated introduction
of a robust way of ensuring that this important system policy would
be preserved across any future toolstack changes.

The XSM hook code in this patch is the same as in OpenXT; the reference
policy is not. The hooks have been validated as behaving correctly on
several generations of Dell and HP Intel-based hardware, with this patch
applied to Xen 4.6, with and without interrupt remapping capability;
and further testing with Xen 4.9 on a subset of that hardware.
The reference policy in this patch has been compile-tested only.

An OpenXT system will still boot even with the IOMMU disabled -- which
is different behaviour than would be the case if the IOMMU was required
via the Xen command line. The system retains its isolation from the
network by preventing passthrough of the NIC(s) to the domain containing
the device drivers, whilst still allowing user access to VMs stored
locally on the system.

Since OpenXT supports older hardware with less capable IOMMUs, its
default configuration is to allow use without interrupt remapping,
but derivative projects of OpenXT with different hardware support
requirements are able to change their policy to the stronger setting
that insists on interrupt remapping availability.

Device isolation can be:
  Useful, eg. for resiliency against occasionally buggy devices
or
  Necessary, eg. strictly required for system security

and sometimes both are true:

The hooks in this patch enable a single XSM policy to be created
for a common software build that is usable across diverse hardware
to express:

  * that allowing GPU passthrough to a particular class of VMs does
    require an IOMMU, but it can proceed without interrupt remapping,

  * whereas the network interface card is not allowed to be used
    by the network driver domain unless an IOMMU is active and
    it has interrupt remapping capability.

 tools/flask/policy/modules/nic_dev.te |  2 +-
 tools/flask/policy/modules/xen.if     | 29 +++++++++++++++++++----
 tools/flask/policy/modules/xen.te     |  3 ++-
 xen/xsm/flask/hooks.c                 | 44 +++++++++++++++++++++++++++++------
 xen/xsm/flask/policy/access_vectors   | 20 ++++++++++++++--
 5 files changed, 83 insertions(+), 15 deletions(-)

Comments

Daniel De Graaf Aug. 18, 2017, 9:55 p.m. UTC | #1

On 08/18/2017 05:02 PM, [e-mail] wrote:
> From: Christopher Clark <[e-mail]>
> 
> Isolation of devices passed through to domains usually requires an
> active IOMMU. The existing method of requiring an IOMMU is via a Xen
> boot parameter ("iommu=force") which will abort boot if an IOMMU is not
> available.
> 
> More graceful degradation of behaviour when an IOMMU is absent can be
> achieved by enabling XSM to perform enforcement of IOMMU requirement.
> 
> This patch enables an enforceable XSM policy to specify that an IOMMU is
> required for particular domains to access devices and how capable that
> IOMMU must be. This allows a Xen system to boot whilst still
> ensuring that an IOMMU is active before permitting device use.
> 
> Using a XSM policy ensures that the isolation properties remain enforced
> even when the large, complex toolstack software changes.
> 
> For some hardware platforms interrupt remapping is a strict requirement
> for secure isolation. Not all IOMMUs provide interrupt remapping.
> The XSM policy can now optionally require interrupt remapping.
> 
> The device use hooks now check whether an IOMMU is:
>   * Active and securely isolating:
>      -- current criteria for this is that interrupt remapping is ok
>   * Active but interrupt remapping is not available
>   * Not active
> 
> This patch also updates the reference XSM policy to use the new
> primitives, with policy entries that do not require an active IOMMU.
> 
> Signed-off-by: Christopher Clark <[e-mail]>

Acked-by: Daniel De Graaf <[e-mail]>

One additional note: if this type of permission expansion needs to be
applied to more permissions based on hypervisor settings, it may be
useful to look at other solutions (such as policy booleans) to implement
this logic.  However, most of those solutions are more complicated than
necessary for a single distinction like this, and the simpler ones do
not provide the same ease of verification that this version has.

Jan Beulich Aug. 22, 2017, 8:18 a.m. UTC | #2

>>> On 18.08.17 at 23:55, <[e-mail]> wrote:
> On 08/18/2017 05:02 PM, [e-mail] wrote:
>> From: Christopher Clark <[e-mail]>
>> 
>> Isolation of devices passed through to domains usually requires an
>> active IOMMU. The existing method of requiring an IOMMU is via a Xen
>> boot parameter ("iommu=force") which will abort boot if an IOMMU is not
>> available.
>> 
>> More graceful degradation of behaviour when an IOMMU is absent can be
>> achieved by enabling XSM to perform enforcement of IOMMU requirement.
>> 
>> This patch enables an enforceable XSM policy to specify that an IOMMU is
>> required for particular domains to access devices and how capable that
>> IOMMU must be. This allows a Xen system to boot whilst still
>> ensuring that an IOMMU is active before permitting device use.
>> 
>> Using a XSM policy ensures that the isolation properties remain enforced
>> even when the large, complex toolstack software changes.
>> 
>> For some hardware platforms interrupt remapping is a strict requirement
>> for secure isolation. Not all IOMMUs provide interrupt remapping.
>> The XSM policy can now optionally require interrupt remapping.
>> 
>> The device use hooks now check whether an IOMMU is:
>>   * Active and securely isolating:
>>      -- current criteria for this is that interrupt remapping is ok
>>   * Active but interrupt remapping is not available
>>   * Not active
>> 
>> This patch also updates the reference XSM policy to use the new
>> primitives, with policy entries that do not require an active IOMMU.
>> 
>> Signed-off-by: Christopher Clark <[e-mail]>
> 
> Acked-by: Daniel De Graaf <[e-mail]>

To be honest, for this kind of a change I would have hoped for
a Reviewed-by (by you or someone else), not just an Acked-by.
Hence I'm hesitant to put the patch in right away.

Jan

Ross Philipson Aug. 23, 2017, 2 p.m. UTC | #3

I did test and review this submission back when I worked on the OpenXT
project with Christopher so I can add a reviewed by.

Reviewed-by: Ross Philipson <[e-mail]>

On Tue, Aug 22, 2017 at 4:18 AM, Jan Beulich <[e-mail]> wrote:

> >>> On 18.08.17 at 23:55, <[e-mail]> wrote:
> > On 08/18/2017 05:02 PM, [e-mail] wrote:
> >> From: Christopher Clark <[e-mail]>
> >>
> >> Isolation of devices passed through to domains usually requires an
> >> active IOMMU. The existing method of requiring an IOMMU is via a Xen
> >> boot parameter ("iommu=force") which will abort boot if an IOMMU is not
> >> available.
> >>
> >> More graceful degradation of behaviour when an IOMMU is absent can be
> >> achieved by enabling XSM to perform enforcement of IOMMU requirement.
> >>
> >> This patch enables an enforceable XSM policy to specify that an IOMMU is
> >> required for particular domains to access devices and how capable that
> >> IOMMU must be. This allows a Xen system to boot whilst still
> >> ensuring that an IOMMU is active before permitting device use.
> >>
> >> Using a XSM policy ensures that the isolation properties remain enforced
> >> even when the large, complex toolstack software changes.
> >>
> >> For some hardware platforms interrupt remapping is a strict requirement
> >> for secure isolation. Not all IOMMUs provide interrupt remapping.
> >> The XSM policy can now optionally require interrupt remapping.
> >>
> >> The device use hooks now check whether an IOMMU is:
> >>   * Active and securely isolating:
> >>      -- current criteria for this is that interrupt remapping is ok
> >>   * Active but interrupt remapping is not available
> >>   * Not active
> >>
> >> This patch also updates the reference XSM policy to use the new
> >> primitives, with policy entries that do not require an active IOMMU.
> >>
> >> Signed-off-by: Christopher Clark <[e-mail]>
> >
> > Acked-by: Daniel De Graaf <[e-mail]>
>
> To be honest, for this kind of a change I would have hoped for
> a Reviewed-by (by you or someone else), not just an Acked-by.
> Hence I'm hesitant to put the patch in right away.
>
> Jan
>
>
> _______________________________________________
> Xen-devel mailing list
> [e-mail]
> https://lists.xen.org/xen-devel
>

Daniel De Graaf Aug. 23, 2017, 3:56 p.m. UTC | #4

On 08/22/2017 04:18 AM, Jan Beulich wrote:
>>>> On 18.08.17 at 23:55, <[e-mail]> wrote:
>> On 08/18/2017 05:02 PM, [e-mail] wrote:
>>> From: Christopher Clark <[e-mail]>
>>>
>>> Isolation of devices passed through to domains usually requires an
>>> active IOMMU. The existing method of requiring an IOMMU is via a Xen
>>> boot parameter ("iommu=force") which will abort boot if an IOMMU is not
>>> available.
>>>
>>> More graceful degradation of behaviour when an IOMMU is absent can be
>>> achieved by enabling XSM to perform enforcement of IOMMU requirement.
>>>
>>> This patch enables an enforceable XSM policy to specify that an IOMMU is
>>> required for particular domains to access devices and how capable that
>>> IOMMU must be. This allows a Xen system to boot whilst still
>>> ensuring that an IOMMU is active before permitting device use.
>>>
>>> Using a XSM policy ensures that the isolation properties remain enforced
>>> even when the large, complex toolstack software changes.
>>>
>>> For some hardware platforms interrupt remapping is a strict requirement
>>> for secure isolation. Not all IOMMUs provide interrupt remapping.
>>> The XSM policy can now optionally require interrupt remapping.
>>>
>>> The device use hooks now check whether an IOMMU is:
>>>    * Active and securely isolating:
>>>       -- current criteria for this is that interrupt remapping is ok
>>>    * Active but interrupt remapping is not available
>>>    * Not active
>>>
>>> This patch also updates the reference XSM policy to use the new
>>> primitives, with policy entries that do not require an active IOMMU.
>>>
>>> Signed-off-by: Christopher Clark <[e-mail]>
>>
>> Acked-by: Daniel De Graaf <[e-mail]>
> 
> To be honest, for this kind of a change I would have hoped for
> a Reviewed-by (by you or someone else), not just an Acked-by.
> Hence I'm hesitant to put the patch in right away.
> 
> Jan

I'll keep that in mind for the future.  I have looked at this patch
in depth, so you can change that to

Reviewed-by: Daniel De Graaf <[e-mail]>

Jan Beulich Aug. 23, 2017, 4:01 p.m. UTC | #5

>>> On 23.08.17 at 17:56, <[e-mail]> wrote:
> On 08/22/2017 04:18 AM, Jan Beulich wrote:
>>>>> On 18.08.17 at 23:55, <[e-mail]> wrote:
>>> On 08/18/2017 05:02 PM, [e-mail] wrote:
>>>> From: Christopher Clark <[e-mail]>
>>>>
>>>> Isolation of devices passed through to domains usually requires an
>>>> active IOMMU. The existing method of requiring an IOMMU is via a Xen
>>>> boot parameter ("iommu=force") which will abort boot if an IOMMU is not
>>>> available.
>>>>
>>>> More graceful degradation of behaviour when an IOMMU is absent can be
>>>> achieved by enabling XSM to perform enforcement of IOMMU requirement.
>>>>
>>>> This patch enables an enforceable XSM policy to specify that an IOMMU is
>>>> required for particular domains to access devices and how capable that
>>>> IOMMU must be. This allows a Xen system to boot whilst still
>>>> ensuring that an IOMMU is active before permitting device use.
>>>>
>>>> Using a XSM policy ensures that the isolation properties remain enforced
>>>> even when the large, complex toolstack software changes.
>>>>
>>>> For some hardware platforms interrupt remapping is a strict requirement
>>>> for secure isolation. Not all IOMMUs provide interrupt remapping.
>>>> The XSM policy can now optionally require interrupt remapping.
>>>>
>>>> The device use hooks now check whether an IOMMU is:
>>>>    * Active and securely isolating:
>>>>       -- current criteria for this is that interrupt remapping is ok
>>>>    * Active but interrupt remapping is not available
>>>>    * Not active
>>>>
>>>> This patch also updates the reference XSM policy to use the new
>>>> primitives, with policy entries that do not require an active IOMMU.
>>>>
>>>> Signed-off-by: Christopher Clark <[e-mail]>
>>>
>>> Acked-by: Daniel De Graaf <[e-mail]>
>> 
>> To be honest, for this kind of a change I would have hoped for
>> a Reviewed-by (by you or someone else), not just an Acked-by.
>> Hence I'm hesitant to put the patch in right away.
> 
> I'll keep that in mind for the future.  I have looked at this patch
> in depth, so you can change that to
> 
> Reviewed-by: Daniel De Graaf <[e-mail]>

Thanks, a few minutes too late though - I've just committed it the
way it was (with Ross' R-b).

Jan

Patch

diff --git a/tools/flask/policy/modules/nic_dev.te b/tools/flask/policy/modules/nic_dev.te
index e0484af..5206f1e 100644
--- a/tools/flask/policy/modules/nic_dev.te
+++ b/tools/flask/policy/modules/nic_dev.te
@@ -11,4 +11,4 @@ 
 type nic_dev_t, resource_type;
 
 admin_device(dom0_t, nic_dev_t)
-use_device(domU_t, nic_dev_t)
+use_device_noiommu(domU_t, nic_dev_t)
diff --git a/tools/flask/policy/modules/xen.if b/tools/flask/policy/modules/xen.if
index ed0df4f..9126400 100644
--- a/tools/flask/policy/modules/xen.if
+++ b/tools/flask/policy/modules/xen.if
@@ -167,11 +167,32 @@  define(`make_device_model', `
 #
 ################################################################################
 
-# use_device(domain, device)
+# use_device_iommu(domain, device)
 #   Allow a device to be used by a domain
-define(`use_device', `
+#   only if an IOMMU provides isolation.
+define(`use_device_iommu', `
     allow $1 $1_self:mmu exchange;
-    allow $1 $2:resource use;
+    allow $1 $2:resource use_iommu;
+    allow $1 domio_t:mmu { map_read map_write };
+')
+
+# use_device_iommu_nointremap(domain, device)
+#   Allow a device to be used by a domain
+#   only if an IOMMU is active, even if it does not support
+#   interrupt remapping.
+#   Allows acceptance of (typically older) less isolating hardware.
+define(`use_device_iommu_nointremap', `
+    allow $1 $1_self:mmu exchange;
+    allow $1 $2:resource { use_iommu use_iommu_nointremap };
+    allow $1 domio_t:mmu { map_read map_write };
+')
+
+# use_device_noiommu(domain, device)
+#   Allow a device to be used by a domain
+#   even without an IOMMU available.
+define(`use_device_noiommu', `
+    allow $1 $1_self:mmu exchange;
+    allow $1 $2:resource { use_iommu use_iommu_nointremap use_noiommu };
     allow $1 domio_t:mmu { map_read map_write };
 ')
 
@@ -180,7 +201,7 @@  define(`use_device', `
 define(`admin_device', `
     allow $1 $2:resource { setup stat_device add_device add_irq add_iomem add_ioport remove_device remove_irq remove_iomem remove_ioport plug unplug };
     allow $1 $2:hvm bind_irq;
-    use_device($1, $2)
+    use_device_noiommu($1, $2)
 ')
 
 # delegate_devices(priv-domain, target-domain)
diff --git a/tools/flask/policy/modules/xen.te b/tools/flask/policy/modules/xen.te
index 0cff2df..3dbf93d 100644
--- a/tools/flask/policy/modules/xen.te
+++ b/tools/flask/policy/modules/xen.te
@@ -67,7 +67,8 @@  allow xen_t resource_type : resource { remove_irq remove_ioport remove_iomem };
 neverallow * ~domain_type:domain { create transition };
 
 # Resources must be declared using resource_type
-neverallow * ~resource_type:resource use;
+neverallow * ~resource_type:resource { use use_iommu use_iommu_nointremap
+                                       use_noiommu };
 
 # Events must use event_type (see create_channel for a template)
 neverallow ~event_type *:event bind;
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 9114627..276ca97 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -20,6 +20,7 @@ 
 #include <xen/errno.h>
 #include <xen/guest_access.h>
 #include <xen/xenoprof.h>
+#include <xen/iommu.h>
 #ifdef CONFIG_HAS_PCI
 #include <asm/msi.h>
 #endif
@@ -886,11 +887,31 @@  static int flask_map_domain_msi (struct domain *d, int irq, void *data,
 #endif
 }
 
+static u32 flask_iommu_resource_use_perm(void)
+{
+    /* Obtain the permission level required for allowing a domain
+     * to use an assigned device.
+     *
+     * An active IOMMU with interrupt remapping capability is essential
+     * for ensuring strict isolation of devices, so provide a distinct
+     * permission for that case and also enable optional support for
+     * less capable hardware (no IOMMU or IOMMU missing intremap capability)
+     * via other separate permissions.
+     */
+    u32 perm = RESOURCE__USE_NOIOMMU;
+
+    if (iommu_enabled)
+        perm = ( iommu_intremap ? RESOURCE__USE_IOMMU :
+                                  RESOURCE__USE_IOMMU_NOINTREMAP );
+    return perm;
+}
+
 static int flask_map_domain_irq (struct domain *d, int irq, void *data)
 {
     u32 sid, dsid;
     int rc = -EPERM;
     struct avc_audit_data ad;
+    u32 dperm = flask_iommu_resource_use_perm();
 
     if ( irq >= nr_static_irqs && data ) {
         rc = flask_map_domain_msi(d, irq, data, &sid, &ad);
@@ -907,7 +928,7 @@  static int flask_map_domain_irq (struct domain *d, int irq, void *data)
     if ( rc )
         return rc;
 
-    rc = avc_has_perm(dsid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
+    rc = avc_has_perm(dsid, sid, SECCLASS_RESOURCE, dperm, &ad);
     return rc;
 }
 
@@ -956,6 +977,7 @@  static int flask_bind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *b
     int rc = -EPERM;
     int irq;
     struct avc_audit_data ad;
+    u32 dperm = flask_iommu_resource_use_perm();
 
     rc = current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__ADD);
     if ( rc )
@@ -972,7 +994,7 @@  static int flask_bind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *b
         return rc;
 
     dsid = domain_sid(d);
-    return avc_has_perm(dsid, rsid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
+    return avc_has_perm(dsid, rsid, SECCLASS_RESOURCE, dperm, &ad);
 }
 
 static int flask_unbind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
@@ -990,6 +1012,7 @@  struct iomem_has_perm_data {
     u32 ssid;
     u32 dsid;
     u32 perm;
+    u32 use_perm;
 };
 
 static int _iomem_has_perm(void *v, u32 sid, unsigned long start, unsigned long end)
@@ -1007,7 +1030,7 @@  static int _iomem_has_perm(void *v, u32 sid, unsigned long start, unsigned long
     if ( rc )
         return rc;
 
-    return avc_has_perm(data->dsid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
+    return avc_has_perm(data->dsid, sid, SECCLASS_RESOURCE, data->use_perm, &ad);
 }
 
 static int flask_iomem_permission(struct domain *d, uint64_t start, uint64_t end, uint8_t access)
@@ -1027,6 +1050,7 @@  static int flask_iomem_permission(struct domain *d, uint64_t start, uint64_t end
 
     data.ssid = domain_sid(current->domain);
     data.dsid = domain_sid(d);
+    data.use_perm = flask_iommu_resource_use_perm();
 
     return security_iterate_iomem_sids(start, end, _iomem_has_perm, &data);
 }
@@ -1041,7 +1065,7 @@  static int flask_pci_config_permission(struct domain *d, uint32_t machine_bdf, u
     u32 dsid, rsid;
     int rc = -EPERM;
     struct avc_audit_data ad;
-    u32 perm = RESOURCE__USE;
+    u32 perm;
 
     rc = security_device_sid(machine_bdf, &rsid);
     if ( rc )
@@ -1050,6 +1074,8 @@  static int flask_pci_config_permission(struct domain *d, uint32_t machine_bdf, u
     /* Writes to the BARs count as setup */
     if ( access && (end >= 0x10 && start < 0x28) )
         perm = RESOURCE__SETUP;
+    else
+        perm = flask_iommu_resource_use_perm();
 
     AVC_AUDIT_DATA_INIT(&ad, DEV);
     ad.device = (unsigned long) machine_bdf;
@@ -1279,6 +1305,7 @@  static int flask_assign_device(struct domain *d, uint32_t machine_bdf)
     u32 dsid, rsid;
     int rc = -EPERM;
     struct avc_audit_data ad;
+    u32 dperm = flask_iommu_resource_use_perm();
 
     rc = current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__ADD);
     if ( rc )
@@ -1295,7 +1322,7 @@  static int flask_assign_device(struct domain *d, uint32_t machine_bdf)
         return rc;
 
     dsid = domain_sid(d);
-    return avc_has_perm(dsid, rsid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
+    return avc_has_perm(dsid, rsid, SECCLASS_RESOURCE, dperm, &ad);
 }
 
 static int flask_deassign_device(struct domain *d, uint32_t machine_bdf)
@@ -1334,6 +1361,7 @@  static int flask_assign_dtdevice(struct domain *d, const char *dtpath)
     u32 dsid, rsid;
     int rc = -EPERM;
     struct avc_audit_data ad;
+    u32 dperm = flask_iommu_resource_use_perm();
 
     rc = current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__ADD);
     if ( rc )
@@ -1350,7 +1378,7 @@  static int flask_assign_dtdevice(struct domain *d, const char *dtpath)
         return rc;
 
     dsid = domain_sid(d);
-    return avc_has_perm(dsid, rsid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
+    return avc_has_perm(dsid, rsid, SECCLASS_RESOURCE, dperm, &ad);
 }
 
 static int flask_deassign_dtdevice(struct domain *d, const char *dtpath)
@@ -1476,6 +1504,7 @@  struct ioport_has_perm_data {
     u32 ssid;
     u32 dsid;
     u32 perm;
+    u32 use_perm;
 };
 
 static int _ioport_has_perm(void *v, u32 sid, unsigned long start, unsigned long end)
@@ -1493,7 +1522,7 @@  static int _ioport_has_perm(void *v, u32 sid, unsigned long start, unsigned long
     if ( rc )
         return rc;
 
-    return avc_has_perm(data->dsid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
+    return avc_has_perm(data->dsid, sid, SECCLASS_RESOURCE, data->use_perm, &ad);
 }
 
 static int flask_ioport_permission(struct domain *d, uint32_t start, uint32_t end, uint8_t access)
@@ -1514,6 +1543,7 @@  static int flask_ioport_permission(struct domain *d, uint32_t start, uint32_t en
 
     data.ssid = domain_sid(current->domain);
     data.dsid = domain_sid(d);
+    data.use_perm = flask_iommu_resource_use_perm();
 
     return security_iterate_ioport_sids(start, end, _ioport_has_perm, &data);
 }
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
index 1f7eb35..f276f04 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -420,11 +420,27 @@  class resource
 #  source = domain making the hypercall
 #  target = domain which will no longer have access to the resource
     remove
+# checked when using some core Xen devices (target xen_t)
+#  source = domain which will have access to the resource
+#  target = xen_t
+    use
 # checked when adding a resource to a domain:
 #  source = domain which will have access to the resource
 #  target = resource's security label
-# also checked when using some core Xen devices (target xen_t)
-    use
+# Requires an active IOMMU capable of interrupt remapping in order to
+# enforce isolation.
+    use_iommu
+# checked when adding a resource to a domain when an IOMMU is available
+# but it is not capable of interrupt mapping:
+#  source = domain which will have access to the resource
+#  target = resource's security label
+# Enable this to allow some less secure systems to still work.
+    use_iommu_nointremap
+# checked when adding a resource to a domain when no IOMMU present:
+#  source = domain which will have access to the resource
+#  target = resource's security label
+# Enable this to allow resource use without an active IOMMU.
+    use_noiommu
 # PHYSDEVOP_map_pirq and ioapic writes for dom0, when acting on real IRQs
 #  For GSI interrupts, the IRQ's label is indexed by the IRQ number
 #  For MSI interrupts, the label of the PCI device is used