From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joanna Rutkowska Subject: IGD passthrough security (was Re: feature suggestion: DMAR table emulation for Xen) Date: Sat, 15 May 2010 19:12:08 +0200 Message-ID: <4BEED5E8.2000707@invisiblethingslab.com> References: <4BED2CD5.4060900@invisiblethingslab.com> <4FA716B1526C7C4DB0375C6DADBC4EA37ACEAA6123@LONPMAILBOX01.citrite.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1410899433==" Return-path: In-Reply-To: <4FA716B1526C7C4DB0375C6DADBC4EA37ACEAA6123@LONPMAILBOX01.citrite.net> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Pratt Cc: "xen-devel@lists.xensource.com" , "Kay, Allen M" , "Cihula, Joseph" , "Han, Weidong" , Keir Fraser List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1410899433== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3BAD454494C44E3789FB62F9" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3BAD454494C44E3789FB62F9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 05/15/2010 06:54 PM, Ian Pratt wrote: >> Well, we don't do graphics passthrough in Qubes, mostly for two reason= s: >> >> 1) We believe users prefer seamless integration of all apps onto one >> desktop (and that requires only one domain, e.g. Dom0, to have access = to >> the graphics card), >=20 > Not necessarily. If dom0 retains control of the display side of the > GPU you can use video overlays to merge in windows from a couple of > other domains. [Though ideally the GPU would use different PCI > requestor IDs for displaying the framebuffer or fetching overlay data > vs rendering] >=20 >> 2) Giving a potentially untrusted domain full access to the graphics >> device creates a potential security risk. In fact, you cannot make suc= h an >> architecture secure without using TXT (yes, TXT in addition to VT-d). >=20 > I agree you can't give an untrusted domain full access, but there's > an interesting design point where you emulate some parts of the GPU > (e.g. anything controlling what is displayed) and pass-through > others. GPU designs that enable you to do this without babysitting > the command rings are obviously preferable... >=20 I've been actually more concerned about the *rich* interface to the GPU that you still must expose to DomU. While semantically it might not be insecure (from what you wrote it might be perhaps possible to prevent DomU from reading the screen buffer, etc), I bet it will contain exploitable implementation flaws. And DomU would be able to exploit them, similarly like one can exploit many modern NIC cards today (see [1]= ). Cheers, joanna. [1] http://theinvisiblethings.blogspot.com/2010/04/remotely-attacking-network= -cards-or-why.html --------------enig3BAD454494C44E3789FB62F9 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/ iEYEARECAAYFAkvu1e0ACgkQORdkotfEW87FDwCgxNyXx8P7dU/aJYyNWGGcewBv 7NwAnijzc3tjxePn/CwcU6PyvBcsfAUn =Mw0d -----END PGP SIGNATURE----- --------------enig3BAD454494C44E3789FB62F9-- --===============1410899433== 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 --===============1410899433==--