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

[Joanna Rutkowska <joanna@xxxxxxxxxxxxxxxxxxxxxx>]

On 07/07/10 17:44, Ian Pratt wrote:
>> So, you're saying that, if we have a device that allows us to set
>> some of its PCI config register (some BAR) to tell where to
>> MMIO-map some of the device's additional config range, and if we
>> "asked it" to map it over, say, some physical addresses belonging
>> to the hypervisor, then the MCH would allow for that? And the CPU
>> would happily redirect access to those addresses over to the device
>> memory? Why would it? That would clearly be a CPU/chipset bug, as
>> we normally would have to mark this memory range as MMIOed in the
>> first place...
> 
> Mapping it over memory might be prevented by the MCH (would you want
> to rely on that?),

Well, we need to rely on the CPU and MCH anyway, so why not? :)

> but mapping it over another device is likely going
> to create system instability if not a vulnerability.
>
>> 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.

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.

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

Can Interrupt Remapping (apparently present in VT-d2) be used to prevent
a device from triggering an #SMI?

Thanks,
joanna.

Attachment: signature.asc
Description: OpenPGP digital signature

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