This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI
From: "Cihula, Joseph" <joseph.cihula@xxxxxxxxx>
Date: Thu, 19 May 2011 13:48:36 -0700
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 19 May 2011 13:49:33 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1305708848.20907.109.camel@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4DD235010200007800070074@xxxxxxxxxxxxxxxxxx> <4F65016F6CB04E49BFFA15D4F7B798D901B773E6D1@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <1305708848.20907.109.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcwVOS1R9pIK01k2QRmx7JIca0YDYgBKhDlQ
Thread-topic: [Xen-devel] Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI
> From: Ian Campbell [mailto:Ian.Campbell@xxxxxxxxxxxxx]
> Sent: Wednesday, May 18, 2011 1:54 AM
> 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;
>              }

So how would the user (or installation SW) specify to use the best (IOMMU) 
security available on the platform?  It looks like this change would again 
either mean giving up on forcing IOMMU or having to alter the command line 
based on knowing what the platform's IR capability is.

I think that it is desirable to have an option that says "use the best IOMMU 
security supported by the platform", and "force" does that right now.

Since what you're really trying to do is to always force IR to be on, why not 
just create a new option "force-intr"?  Or if your goal is to force the use of 
the best security capabilities available on any platform, and fail on the rest, 
then define a new option for that.

> 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.
Xen-devel mailing list