RE: [Xen-devel] pciback: question about the permissive flag

[Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>]

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