Re: [early RFC] ARM PCI Passthrough design document

[Julien Grall <julien.grall@linaro.org>]

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@lists.xen.org
https://lists.xen.org/xen-devel