WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Subject: RE: [Xen-devel] Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI
From: "Cihula, Joseph" <joseph.cihula@xxxxxxxxx>
Date: Fri, 20 May 2011 09:02:04 -0700
Accept-language: en-US
Acceptlanguage: en-US
Cc: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 20 May 2011 09:10:19 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20110520101715.GB27118@xxxxxxxxxxxxxxxxxxxxxxx>
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> <4F65016F6CB04E49BFFA15D4F7B798D901B77B4CAF@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20110520101715.GB27118@xxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcwW1yHm68/aOI7BRz2GES8XicrB5QAIPIKw
Thread-topic: [Xen-devel] Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI
> From: Tim Deegan [mailto:Tim.Deegan@xxxxxxxxxx]
> Sent: Friday, May 20, 2011 3:17 AM
> 
> At 21:48 +0100 on 19 May (1305841716), Cihula, Joseph wrote:
> > So how would the user (or installation SW) specify to use the best
> > (IOMMU) security available on the platform?
> 
> iommu=on.  That pretty much lines up with the current meaining.

'iommu=on' is really "*try* to use the best but it's OK if you can't", as it 
will allow execution to continue even if enabling the supported features fails. 
 'force' is really this with the caveat that execution won't continue if it 
fails to enable them.

> Only iommu=force requires a fully secure IOMMU, and you can overide that with
> iommu=force,nointremap.

But as I said, if you're writing a Xen installer and you want to *ensure* that 
Xen uses the HW features of the system, are you going to make some table that 
tells whether any given system supports IR so that you know which ones to add 
',nointremap' to?  Because if you try to detect it at install time, malware 
could convince you to disable IR even though the HW supports it and TXT would 
report correctly to Xen.

What is the reason for not creating a new option that supports your desired 
behavior?

Joe
> 
> Tim.
> 
> --
> Tim Deegan <Tim.Deegan@xxxxxxxxxx>
> Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd.  
> (Company #02937203, SL9
> 0BG)

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

<Prev in Thread] Current Thread [Next in Thread>