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


IGD passthrough security (was Re: [Xen-devel] feature suggestion: DMAR t

To: Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>
Subject: IGD passthrough security (was Re: [Xen-devel] feature suggestion: DMAR table emulation for Xen)
From: Joanna Rutkowska <joanna@xxxxxxxxxxxxxxxxxxxxxx>
Date: Sat, 15 May 2010 19:12:08 +0200
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Kay, Allen M" <allen.m.kay@xxxxxxxxx>, "Cihula, Joseph" <joseph.cihula@xxxxxxxxx>, "Han, Weidong" <weidong.han@xxxxxxxxx>, Keir Fraser <Keir.Fraser@xxxxxxxxxxxxx>
Delivery-date: Sat, 15 May 2010 10:10:10 -0700
Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:date:from:mime-version:to:cc:subject:references:in-reply-to:content-type; s=smtpout; bh=hi1BgPqkQ0KI5TYzEfpAYZuNeY8=; b=iNDls2GrBM33r/Yu7yzU4JsLttc8Jq8TFmUyLwJFftjOKWuRLTmdh6iHACnKQ6CYiFCBQdJSgkL8Z1z44nFb+Puo50qnL0ZOqH9gZmZxBunoTJWIBhZ/vJ/OMWDFqjJJNUp9A/iOK/IpaaKakcQDtdCkc4r/An6eOtAU2T3AIOM=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4FA716B1526C7C4DB0375C6DADBC4EA37ACEAA6123@xxxxxxxxxxxxxxxxxxxxxxxxx>
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: <C812E911.144DD%keir.fraser@xxxxxxxxxxxxx> <4BED2CD5.4060900@xxxxxxxxxxxxxxxxxxxxxx> <4FA716B1526C7C4DB0375C6DADBC4EA37ACEAA6123@xxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100330 Fedora/3.0.4-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.4
On 05/15/2010 06:54 PM, Ian Pratt wrote:
>> Well, we don't do graphics passthrough in Qubes, mostly for two reasons:
>> 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),
> 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]
>> 2) Giving a potentially untrusted domain full access to the graphics
>> device creates a potential security risk. In fact, you cannot make such an
>> architecture secure without using TXT (yes, TXT in addition to VT-d).

> 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...

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]).



Attachment: signature.asc
Description: OpenPGP digital signature

Xen-devel mailing list
<Prev in Thread] Current Thread [Next in Thread>