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] pciback: question about the permissive flag

To: Joanna Rutkowska <joanna@xxxxxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] pciback: question about the permissive flag
From: Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>
Date: Wed, 7 Jul 2010 23:51:18 +0100
Accept-language: en-US
Acceptlanguage: en-US
Cc: Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <Keir.Fraser@xxxxxxxxxxxxx>
Delivery-date: Wed, 07 Jul 2010 15:53:22 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4C34F478.6050901@xxxxxxxxxxxxxxxxxxxxxx>
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: <4C33A217.3050006@xxxxxxxxxxxxxxxxxxxxxx> <C859DDFC.1996A%keir.fraser@xxxxxxxxxxxxx> <4FA716B1526C7C4DB0375C6DADBC4EA37ACFC7A459@xxxxxxxxxxxxxxxxxxxxxxxxx> <4C3489B8.7050800@xxxxxxxxxxxxxxxxxxxxxx> <4FA716B1526C7C4DB0375C6DADBC4EA37ACFC7A473@xxxxxxxxxxxxxxxxxxxxxxxxx> <4C34F478.6050901@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcseHRD2I1tn9zwrRHCy5QNMhTkpYAABDm3A
Thread-topic: [Xen-devel] pciback: question about the permissive flag
> >> And even if we wanted to instruct the device to map its memory over
> >> some already MMIOed memory in a hypervisor, shouldn't VT-d prevent
> >> the read/write transactions going to this device?
> >
> > VT-d only deals with DMAs coming from the device, not CPU MMIOs.
> >
> 
> So, we would have two devices on the PCIe bus that would be willing to
> respond for a single PCI read request (for some address that both of the
> devices map some of their memory). I guess which device would actually
> answer would be implementation/race-condition specific.

On a PCI bus there's definitely opportunity for races. 
On a PCIe bus I'm not entirely sure what would happen as the bridge/IOH 
presumably has an opinion of which addresses should be routed through which 
ports. [You also have to be careful of multiple devices behind non-ACS capable 
bridges where creating a new BAR could cause DMAs to go peer-to-peer.]
 
> Let assume the "bad" device answers the PCIe read request first, and will
> send its data back (this is what the attacker hopes to achieve -- to feed
> unexpected data into the hypervisor/Dom0). Are you saying that VT-d would
> not prevent this answer coming back to the CPU? Can somebody from Intel
> comment on this? This is interesting.

VT-d only gets involved with transactions initiated by the device (i.e. DMAs). 
Control/remapping of MMIO transactions initiated by the CPU are handled by the 
normal CPU MMU.

> >> As for the SMI generation: that stinks indeed. But, does it offer any
> >> control over the generated #SMI, e.g. what we write into the
> >> 0xb2 port, or something like that?
> >
> > No idea. Discarding such config writes just seems like a good default.
> >
> 
> So far I've been aware that the southbridge can trigger #SMI in response
> to certain conditions, e.g. wrong BDF address (which is apparently used by
> OEMs to emulate PCI devices from within SMM, how crazy is this?!).
> But what would be the reason to let IGD device to trigger #SMI?

Probably something like OpRegion doorbells.
 
> Can Interrupt Remapping (apparently present in VT-d2) be used to prevent a
> device from triggering an #SMI?

Er, that's beyond my knowledge...
 

Ian



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