Hi Vijay, > -----Original Message----- > From: Vijay Kumar Srivastava <vsriv...@xilinx.com> > Sent: Saturday, October 2, 2021 1:32 AM > To: Xia, Chenbo <chenbo....@intel.com>; dev@dpdk.org > Cc: maxime.coque...@redhat.com; andrew.rybche...@oktetlabs.ru; Harpreet > Singh Anand <han...@xilinx.com>; Praveen Kumar Jain <prave...@xilinx.com> > Subject: RE: [PATCH 02/10] vdpa/sfc: add support for device initialization > > Hi Chenbo, > > >-----Original Message----- > >From: Xia, Chenbo <chenbo....@intel.com> > >Sent: Monday, September 6, 2021 8:32 AM > >To: Vijay Kumar Srivastava <vsriv...@xilinx.com>; dev@dpdk.org > >Cc: maxime.coque...@redhat.com; andrew.rybche...@oktetlabs.ru; Harpreet > >Singh Anand <han...@xilinx.com>; Praveen Kumar Jain <prave...@xilinx.com> > >Subject: RE: [PATCH 02/10] vdpa/sfc: add support for device > initialization > > > >Hi, > > > >> -----Original Message----- > >> From: Vijay Kumar Srivastava <vsriv...@xilinx.com> > >> Sent: Friday, September 3, 2021 9:20 PM > >> To: Xia, Chenbo <chenbo....@intel.com>; dev@dpdk.org > >> Cc: maxime.coque...@redhat.com; andrew.rybche...@oktetlabs.ru; > >> Harpreet Singh Anand <han...@xilinx.com>; Praveen Kumar Jain > >> <prave...@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.
Yes, I think I know your solution of driver solving the overlap problem. > 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 ? As I have not reviewed the full series and not familiar with your HW. You can correct my understanding below: I think your vdpa HW (let's say a VF) have two DMA regions: one in guest (w/o vIOMMU) and the other in vdpa app. Both share the same IOVA address space, and we don't want them overlap. Let's say we can make sure no overlap will happen and take an example here: guest DMA region's IOVA (GPA) range is 0x0000 to 0x1000 and vdpa app's is 0x1000 to 0x2000. A malicious guest could use a malicious driver to write 0x1500 in its virtio RX ring, so that HW will DMA to that address when packets come. Then the malicious guest performed an DMA to host memory. Although the guest does not know IOVA range of vdpa app, he can randomly guess to do the attack. Any solution your HW/driver can prevent this from happening without PASID? Or do I miss something here? Thanks, Chenbo > > >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 >
