[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 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
Lists.xenproject.org is hosted with RackSpace, monitoring our