Re: pciback: question about the permissive flag

[Joanna Rutkowska <joanna@invisiblethingslab.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2253 bytes --]

On 07/07/10 15:30, Ian Pratt wrote:
>> I think the fear was that there could be class- or device-specific
>> config registers that we wouldn't know how to handle, and which
>> could have unexpected effects if they are passed through naively.
>> Concrete examples were never given, and this was all pre-vtd so as
>> you say pass-through of a DMA-capable device was insecure anyway.
>> I've always thought the permissive flag stuff was pretty useless,
>> and I always suggest people to enable the permissive flag.
> 
> There are some devices (typically integrated ones, e.g. igfx) that
> use PCI config space in nasty ways, such as to describe additional
> BARs, or to trigger SMIs. Allowing free access to these seems
> dangerous.
> 

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

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?

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? If it doesn, then surely it's an avenue for
DomU->SMM escalation, which would mean full system compromise.

I'm trying to figure out why so many drivers do not work well when run
in a PV driver domain (specifically net drivers), but work fine when
running in Dom0. Clearly this is not a pfn != mfn problem, as this
inequality also applies to Dom0, while in Dom0 the same drivers work
just fine. So it seems like it could only be caused by either of the
following:
1) restricted access to device config space
2) interrupt routing problem

Or maybe something else?

Thanks,
joanna.


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 226 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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