[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [early RFC] ARM PCI Passthrough design document

Hi Stefano,

On 01/02/2017 19:31, Stefano Stabellini wrote:
On Wed, 1 Feb 2017, Julien Grall wrote:
On 31/01/2017 19:06, Edgar E. Iglesias wrote:
On Tue, Jan 31, 2017 at 05:09:53PM +0000, Julien Grall wrote:
On 31/01/17 16:53, Edgar E. Iglesias wrote:
On Wed, Jan 25, 2017 at 06:53:20PM +0000, Julien Grall wrote:
On 24/01/17 20:07, Stefano Stabellini wrote:
On Tue, 24 Jan 2017, Julien Grall wrote:
From my understanding your MSI controller is embedded in the hostbridge,
right? If so, the MSIs would need to be handled where the host bridge will be
initialized (e.g either Xen or DOM0).

From a design point of view, it would make more sense to have the MSI
controller driver in Xen as the hostbridge emulation for guest will also live

So if we receive MSI in Xen, we need to figure out a way for DOM0 and guest to
receive MSI. The same way would be the best, and I guess non-PV if possible. I
know you are looking to boot unmodified OS in a VM. This would mean we need to
emulate the MSI controller and potentially xilinx PCI controller. How much are
you willing to modify the OS?

Regarding the MSI doorbell, I have seen it is configured by the software using
a physical address of a page allocated in the RAM. When the PCI devices is
writing into the doorbell does the access go through the SMMU?

Regardless the answer, I think we would need to map the MSI doorbell page in
the guest.

Why? We should be able to handle the case by trapping and emulating PCI
config accesses. Xen can force the real MSI descriptors to use whatever
Xen wants them to use. With an SMMU, we need to find a way to map the
MSI doorbell in the SMMU pagetable to allow the device to write to it.
Without SMMU, it's unneeded.

My point was using guest with SMMU, if you want to support PCI passthrough without SMMU then it is another subject and I would rather postpone this discussion.

Meaning that even if we trap MSI configuration access, a guess
could DMA in the page. So if I am not mistaken, MSI would be insecure in this
case :/.

That's right: if a device capable of DMA to an arbitrary address in
memory is assigned to the guest, the guest can write to the MSI doorbell
if an SMMU is present, otherwise, the guest can write to any address in
memory without SMMU. Completely insecure.

It is the same security compromised offered by PV PCI passthrough today
with no VT-D on the platform. I think it's still usable in some cases,
but we need to be very clear about its security properties.

The guest would have to be mapped 1:1 in order to do DMA. And this is not supported today.

Or maybe we could avoid mapping the doorbell in the guest and let Xen receive
an SMMU abort. When receiving the SMMU abort, Xen could sanitize the value and
write into the real MSI doorbell. Not sure if it would works thought.

I thought that SMMU aborts are too slow for this?

I got no idea here. However, I think it would be better than a security hole. So this could be an option for the user.


Julien grall

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.