From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joanna Rutkowska Subject: Re: Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI Date: Fri, 13 May 2011 13:08:16 +0200 Message-ID: <4DCD1120.5020606@invisiblethingslab.com> References: <19915.58644.191837.671729@mariner.uk.xensource.com> <4DCD030902000078000412C8@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0954395238==" Return-path: In-Reply-To: <4DCD030902000078000412C8@vpn.id2.novell.com> 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 Cc: Keir Fraser , xen-devel@lists.xensource.com, Ian Jackson List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0954395238== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDA0C805E4D4CD4162E240220" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDA0C805E4D4CD4162E240220 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 05/13/11 10:08, Jan Beulich wrote: >>>> On 12.05.11 at 15:48, Ian Jackson wrote:= >> Intel VT-d chipsets without interrupt remapping do not prevent a guest= >> which owns a PCI device from using DMA to generate MSI interrupts by >> writing to the interrupt injection registers. This can be exploited >> to inject traps and gain control of the host. >=20 > Isn't that (or at least can't that be) prevented with DMA remapping? >=20 No. That's sort of the key point here, and the reason why IR hardware is required. >> The first patch is intended to reduce the impact from full privilege >> escalation to denial of service. >> Filename: 00-block-msis-on-trap-vectors >> SHA1: 0fcc1914714c228e98b3e84597e06cb5de09003c >> SHA256: 998e8d5632ee6ad92f52796fe94923f9c38096c5adf2ca74209a6792436ea= 1e9 >=20 > You modify only 64-bit and only VT-d code here. While I know you > don't care much for it, doing the same for 32-bit would seem trivial. >=20 > As to AMD's IOMMU, it may well be that interrupt re-mapping isn't > optional in the hardware (albeit it can be disabled on the command > line, though that's the admin's security risk then), but the code > having BUG_ON()s on failed allocations and those allocations > happening in table parsing callbacks doesn't really make this > explicit (for me at least) on the first glance. >=20 > Finally, wouldn't killing all guests that potentially could have caused= > the problem be a better measure than bringing down the host? >=20 Killing the guest might no longer be enough, because the guest might have already programmed the device to keep sending malicious MSIs. So, panic()ing the whole VMM seems like a safer choice. Keep in mind that on a non-IR hardware there are probably many other ways for the malicious driver domain to cause global DoS. (In fact, my impression is that most people regarded IR as an anti-DoS mechanism, and I believe our paper is the first to show that the problems were far worse than possible DoS.) joanna. > Jan >=20 >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel --------------enigDA0C805E4D4CD4162E240220 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNzREgAAoJEDaIqHeRBUM0YzwH/30wwwtrX1sdE1KQFotgiMmN 0NtRWJDA1gkyXZqRdoeRK2cS9VlsRpFuMA8aW6VD4svsFz38MtMWGGWwwjhIhd0k dtKcAi0TM4X5qqlQ5sv9mQG6I+EOa3D+lwcqplfqCvB3LrOTovyXHlVTbpXAVl4D RLNA05cHwzLlLMRpI5rGkaFf2/RUvSZkVtKhl8fxcHT34JwMD+tjX5yPD9snrPUm IH0w1bJ9dQktR3NA8yAAmCT1tgpKfTJNRl4M5PwhMKFwiHrF1q9S1JpLyJpGoZtf 0uit/JC4gojX84T165WZaRuvQFLbt4u0y+6zYMeLhcHKK4l/Xf7J5VwpQMFk3AQ= =8L6X -----END PGP SIGNATURE----- --------------enigDA0C805E4D4CD4162E240220-- --===============0954395238== 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 --===============0954395238==--