[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] xsm: policy hooks to require an IOMMU and interrupt remapping
On 08/18/2017 05:02 PM, christopher.w.clark@xxxxxxxxx wrote: From: Christopher Clark <christopher.clark6@xxxxxxxxxxxxxx> 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 <christopher.clark6@xxxxxxxxxxxxxx> Acked-by: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> 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. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |