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

[Julien Grall <julien.grall@xxxxxxxxxx>]

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
> > there.
> >
> > 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.
Cheers,

--
Julien grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel