File xsa304-1.patch of Package xen.13142

x86/vtd: Hide superpage support for SandyBridge IOMMUs

Something causes SandyBridge IOMMUs to choke when sharing EPT pagetables, and
an EPT superpage gets shattered.  The root cause is still under investigation,
but the end result is unusable in combination with CVE-2018-12207 protections.

This is part of XSA-304 / CVE-2018-12207

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1257,6 +1257,30 @@ int __init iommu_alloc(struct acpi_drhd_
     if ( !iommu->domid_map )
         return -ENOMEM ;
 
+    /*
+     * IOMMU Quirks:
+     *
+     * SandyBridge IOMMUs claim support for 2M and 1G superpages, but don't
+     * implement superpages internally.
+     *
+     * There are issues changing the walk length under in-flight DMA, which
+     * makes EPT/IOMMU sharing incompatible with the workaround for
+     * CVE-2018-12207 / XSA-304.  Furthermore, performance numbers suggest
+     * using 4k mappings is faster than 2M mappings anyway.
+     *
+     * Hide the superpages capabilities in the IOMMU.  This will prevent Xen
+     * from sharing the EPT and IOMMU pagetables.
+     *
+     * Detection of SandyBridge unfortunately has to be done by processor
+     * model because the client parts don't expose their IOMMUs as PCI devices
+     * we could match with a Device ID.
+     */
+    if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &&
+         boot_cpu_data.x86 == 6 &&
+         (boot_cpu_data.x86_model == 0x2a ||
+          boot_cpu_data.x86_model == 0x2d) )
+        iommu->cap &= ~(0xful << 34);
+
     spin_lock_init(&iommu->lock);
     spin_lock_init(&iommu->register_lock);