From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Cihula, Joseph" Subject: RE: Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI Date: Tue, 17 May 2011 15:52:22 -0700 Message-ID: <4F65016F6CB04E49BFFA15D4F7B798D901B773E6D1@orsmsx506.amr.corp.intel.com> References: <4DD235010200007800070074@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1688216132==" Return-path: In-Reply-To: <4DD235010200007800070074@vpn.id2.novell.com> Content-Language: en-US List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich , "Ian.Campbell@citrix.com" Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org --===============1688216132== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_4F65016F6CB04E49BFFA15D4F7B798D901B773E6D1orsmsx506amrc_" --_000_4F65016F6CB04E49BFFA15D4F7B798D901B773E6D1orsmsx506amrc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Jan Beulich [mailto:jbeulich@novell.com] Sent: Tuesday, May 17, 2011 12:43 AM To: Ian.Campbell@citrix.com; Cihula, Joseph Cc: xen-devel@lists.xensource.com Subject: RE: [Xen-devel] Xen security advisory CVE-2011-1898 - VT-d (PCI pa= ssthrough) MSI >>> "Cihula, Joseph" > 05/16/11 11:34 PM >>> >IOMMU adds security capabilities. IR adds additional security capabilities= . IOMMU allows for fully isolating the hypervisor >from domains even if the domains control DMA devices. It helps to protect = against buggy drivers or device FW by limiting >the areas such bugs can affect to just the DMA data buffers. IOMMU, in con= junction with Intel(R) Trusted Execution >Technology (TXT), provides DMA protection through the entire launch proces= s and into runtime. This is all true regardless >of the presence of IR. IR adds the ability to prevent DoS attacks by untru= sted domains with assigned DMA devices, >malicious device FW, etc. This is incremental--not all or nothing. I think this is the problem - you're saying things like "fully isolating" a= nd "regardless of the presence of IR", while the paper they made accessible [JC] I will admit to being a little overreaching in use of that adverb; le= t's remove "fully" and my statement still stands. meanwhile makes clear that neither is true. Thus the mere presence of DMA p= rotection creates false expectation of customers - without IR (and with MSI= supported by the system, not necessarily the device passed through) there'= s no way for isolation to become complete (actually, with non-MSI-capable d= evices or by disallowing MSI altogether on capable ones, depending of wheth= er MSI writes bypass the IOMMU or simply get 1:1 translated, it could be po= ssible to make this secure). [JC] The expectations of users will depend on the features advertised and = how they are implemented in the SW solutions that use IOMMU. Such SW shoul= d not be advertising DoS protection if devices are assigned to untrusted do= mains on systems without IR. Just like it should not advertise that on sys= tems without IOMMU. (Note that the DMA protection of IOMMU should prevent = most/all accidental/buggy behaviors; MSI DoS would almost certainly have to= be due to malicious code.) >The 00-block-msis-on-trap-vectors patch (esp. in conjunction with TXT) pre= vents all known security exploits of MSI misuse. All? Not really, just a very small subset, and only partially. The SIPI one= is perhaps the worst case (not prevented by this patch), but being able to= send SMI or NMI perhaps isn't much better (as long as we're considering Do= S attacks to also be a problem, which at least I do, and in which case said= patch only converts from one [worse] to another ["better"] evil). [JC] I didn't say "all exploits"-I said all *known* exploits, and that is = correct. The SIPI attack, which isn't known to be exploitable, is prevente= d by TXT (hence the "esp. in conjunction with TXT" in my statement). Natur= ally, DoS attacks are problematic from a reliability perspective but they w= ere not what I was referring to with the term "security exploit". 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 ex= pectations is through SW freezing. Jan --_000_4F65016F6CB04E49BFFA15D4F7B798D901B773E6D1orsmsx506amrc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From: Jan Beulic= h [mailto:jbeulich@novell.com]
Sent: Tuesday, May 17, 2011 12:43= AM
To: Ian.Campbell@citrix.com; Cihula, Joseph
Cc: xen= -devel@lists.xensource.com
Subject: RE: [Xen-devel] Xen security = advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI

 

>>> "Cih= ula, Joseph" <joseph.cih= ula@intel.com> 05/16/11 11:34 PM >>>
>IOMMU adds secu= rity capabilities. IR adds additional security capabilities. IOMMU allows f= or fully isolating the hypervisor
>from domains even if the domains c= ontrol DMA devices. It helps to protect against buggy drivers or device FW = by limiting
>the areas such bugs can affect to just the DMA data buff= ers. IOMMU, in conjunction with Intel(R) Trusted Execution
>Technolog= y (TXT), provides DMA protection through the entire launch process and into= runtime. This is all true regardless
>of the presence of IR. IR adds= the ability to prevent DoS attacks by untrusted domains with assigned DMA = devices,
>malicious device FW, etc. This is incremental--not all or n= othing.

I think this is the problem - you're saying things like &quo= t;fully isolating" and "regardless of the presence of IR", w= hile the paper they made accessible

[JC]  I will admit to b= eing a little overreaching in use of that adverb; let’s remove “= ;fully” and my statement still stands.

 

meanwhile mak= es clear that neither is true. Thus the mere presence of DMA protection cre= ates false expectation of customers - without IR (and with MSI supported by= the system, not necessarily the device passed through) there's no way for = isolation to become complete (actually, with non-MSI-capable devices or by = disallowing MSI altogether on capable ones, depending of whether MSI writes= bypass the IOMMU or simply get 1:1 translated, it could be possible to mak= e this secure).

<= p class=3DMsoNormal>[JC]  The expectations of users will depend= on the features advertised and how they are implemented in the SW solution= s that use IOMMU.  Such SW should not be advertising DoS protection if= devices are assigned to untrusted domains on systems without IR.  Jus= t like it should not advertise that on systems without IOMMU.  (Note t= hat the DMA protection of IOMMU should prevent most/all accidental/buggy be= haviors; MSI DoS would almost certainly have to be due to malicious code.)<= o:p>

 

>The 00-block-msis-on-trap-vectors patch (esp. in conjunct= ion with TXT) prevents all known security exploits of MSI misuse.

Al= l? Not really, just a very small subset, and only partially. The SIPI one i= s perhaps the worst case (not prevented by this patch), but being able to s= end SMI or NMI perhaps isn't much better (as long as we're considering DoS = attacks to also be a problem, which at least I do, and in which case said p= atch only converts from one [worse] to another ["better"] evil).<= br>[JC]  I didn’t say “all e= xploits”—I said all *known* exploits, and that is correc= t.  The SIPI attack, which isn’t known to be exploitable, is pre= vented by TXT (hence the “esp. in conjunction with TXT” in my statement).  Naturally, DoS attack= s are problematic from a reliability perspective but they were not what I w= as referring to with the term “security exploit”.

 

I still fail to see an argument that justifies panic&= #8217;ing Xen when IOMMU is enabled on non-IR systems.  And I don̵= 7;t think the way to manage customer expectations is through SW freezing.

 


Jan

= --_000_4F65016F6CB04E49BFFA15D4F7B798D901B773E6D1orsmsx506amrc_-- --===============1688216132== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1688216132==--