RE: [Xen-devel] Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

On Tue, 2011-05-17 at 23:52 +0100, Cihula, Joseph wrote:
> I still fail to see an argument that justifies panicâing Xen when
> IOMMU is enabled on non-IR systems.  And I donât think the way to
> manage customer expectations is through SW freezing.

Leaving the iommu=on behaviour the same as today but making iommu=force
require IR (with an explicit opt-out a la iommu=force,no-intremap) is
possibly sufficient (and considerably less harsh than the previous
proposal).

Perhaps something like the following? 

# HG changeset patch
# Parent 3db330334e3512a5326bbed4881718a63eec171a
diff -r 3db330334e35 -r 975cd3817d7a xen/drivers/passthrough/vtd/iommu.c
--- a/xen/drivers/passthrough/vtd/iommu.c       Fri May 13 14:41:18 2011 +0100
+++ b/xen/drivers/passthrough/vtd/iommu.c       Mon May 16 11:37:41 2011 +0100
@@ -1987,7 +1987,7 @@ static int init_vtd_hw(void)
                 dprintk(XENLOG_WARNING VTDPREFIX,
                         "Interrupt Remapping not enabled\n");
 
-                if ( force_iommu && platform_supports_intremap() )
+                if ( force_iommu )
                     panic("intremap remapping failed to enable with 
iommu=required/force in grub\n");
                 break;
             }

I also considered 
+               if ( force_iommy && ( !tboot_in_measured_env() || 
platform_supports_intremap() )

but I trusting the result of tboot_in_measured_env() in the non-TXT case
seems a bit silly.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel