[dpdk-dev] [PATCH 02/10] vdpa/sfc: add support for device initialization

[Vijay Kumar Srivastava]

Hi Chenbo,

>-----Original Message-----
>From: Xia, Chenbo <chenbo.xia at intel.com>
>Sent: Monday, September 6, 2021 8:32 AM
>To: Vijay Kumar Srivastava <vsrivast at xilinx.com>; dev at dpdk.org
>Cc: maxime.coquelin at redhat.com; andrew.rybchenko at oktetlabs.ru; Harpreet
>Singh Anand <hanand at xilinx.com>; Praveen Kumar Jain <praveenj at xilinx.com>
>Subject: RE: [PATCH 02/10] vdpa/sfc: add support for device initialization
>
>Hi,
>
>> -----Original Message-----
>> From: Vijay Kumar Srivastava <vsrivast at xilinx.com>
>> Sent: Friday, September 3, 2021 9:20 PM
>> To: Xia, Chenbo <chenbo.xia at intel.com>; dev at dpdk.org
>> Cc: maxime.coquelin at redhat.com; andrew.rybchenko at oktetlabs.ru;
>> Harpreet Singh Anand <hanand at xilinx.com>; Praveen Kumar Jain
>> <praveenj at xilinx.com>
>> Subject: RE: [PATCH 02/10] vdpa/sfc: add support for device
>> initialization
>>

[snip]

>> To handle IOVA overlap detection scenario a patch is in progress 
>> which will be submitted soon.
>> In that patch, upon IOVA overlap detection new available IOVA would 
>> be calculated and MCDI buffer would be remapped to new IOVA.
>Let's say there is a malicious guest who knows your initial IOVA range that is set
>up by your driver (even if it does not know, it can use tests to know. So use static
>IOVA range in host is more dangerous). 
Upcoming patch will handle IOVA conflict scenario. With that patch hardcoded IOVA would not be needed.
If malicious guest will try to use MCDI IOVA address then vDPA driver would detect IOVA overlap and would remap MCDI buffer to another available IOVA address.
This IOVA address is for MCDI buffer which is used for the control path.
Just by only writing to MCDI buffer does not imply that malicious guest can send any control message to NIC to modify HW configuration.

>It can use that address in any DMA-able queue and make DMA into the vdpa app. I think it could cause some security issue
>as you let guest easily writing host memory.
Can you please elaborate on this ? 
In what scenarios host physical address can be accessed by malicious guest ?

>For now I don't see a perfect solution except PASID(Process Address Space ID).
>IIRC, We could let QEMU have a primary PASID and vdpa app have a secondary
>PASID so that VM can't perform DMA to vdpa app. But since it needs HW support
>and related support in vfio is not mature, I don't think we are able to use that
>solution now.
>Any solution you can think of for your HW?
Yes, It can be used. Our next version of HW will have the PASID support.

Regards,
Vijay