[dpdk-dev] [PATCH v13 2/2] eal: support for VFIO-PCI VF token

[Wang, Haiyue]

+Alex

> -----Original Message-----
> From: Andrew Rybchenko <arybchenko at solarflare.com>
> Sent: Thursday, May 7, 2020 00:59
> To: Wang, Haiyue <haiyue.wang at intel.com>; dev at dpdk.org; Burakov, Anatoly <anatoly.burakov at intel.com>;
> thomas at monjalon.net; jerinj at marvell.com; david.marchand at redhat.com
> Subject: Re: [dpdk-dev] [PATCH v13 2/2] eal: support for VFIO-PCI VF token
> 
> On 5/6/20 7:56 PM, Wang, Haiyue wrote:
> >> -----Original Message-----
> >> From: Andrew Rybchenko <arybchenko at solarflare.com>
> >> Sent: Thursday, May 7, 2020 00:51
> >> To: Wang, Haiyue <haiyue.wang at intel.com>; dev at dpdk.org; Burakov, Anatoly
> <anatoly.burakov at intel.com>;
> >> thomas at monjalon.net; jerinj at marvell.com; david.marchand at redhat.com
> >> Subject: Re: [dpdk-dev] [PATCH v13 2/2] eal: support for VFIO-PCI VF token
> >>
> >> On 5/6/20 2:35 PM, Haiyue Wang wrote:
> >>> The kernel module vfio-pci introduces the VF token to enable SR-IOV
> >>> support since 5.7.
> >>>
> >>> The VF token can be set by a vfio-pci based PF driver and must be known
> >>> by the vfio-pci based VF driver in order to gain access to the device.
> >>>
> >>> Signed-off-by: Haiyue Wang <haiyue.wang at intel.com>
> >>> Acked-by: Anatoly Burakov <anatoly.burakov at intel.com>
> >>
> >> Sorry, lost from my view new versions of the patch series.
> >>
> >> Acked-by: Andrew Rybchenko <arybchenko at solarflare.com>
> >>
> >>> diff --git a/doc/guides/linux_gsg/linux_drivers.rst b/doc/guides/linux_gsg/linux_drivers.rst
> >>> index 238f3e900..910397243 100644
> >>> --- a/doc/guides/linux_gsg/linux_drivers.rst
> >>> +++ b/doc/guides/linux_gsg/linux_drivers.rst
> >>> @@ -72,11 +72,44 @@ Note that in order to use VFIO, your kernel must support it.
> >>>  VFIO kernel modules have been included in the Linux kernel since version 3.6.0 and are usually
> >> present by default,
> >>>  however please consult your distributions documentation to make sure that is the case.
> >>>
> >>> +The ``vfio-pci`` module since Linux version 5.7 supports the creation of virtual
> >>> +functions. After the PF is bound to vfio-pci module, the user can create the VFs
> >>> +by sysfs interface, and these VFs are bound to vfio-pci module automatically.
> >>> +
> >>> +When the PF is bound to vfio-pci, it has initial VF token generated by random. For
> >>> +security reason, this token is write only, the user can't read it from the kernel
> >>> +directly. For accessing the VF, the user needs to start the PF with token parameter
> >>> +to setup a VF token (uuid format), then the VF can be accessed with this new known
> >>> +VF token.
> >>
> >> If token is write-only in kernel sysfs, shouldn't we make it
> >> invisible in ps output? I.e. substitute with something like
> >> xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.
> >> It is a bit easier with the new design. Just a thought.
> >>
> >
> > In fact, no sysfs for VF token, just write-only IOCTL. ;-)
> 
> OK, got it. The question remains anyway. Should it be treated
> as a secret with at least minimal security precaution?
>

Sounds yes, and also it looks like be more friendly for user to check whether
this PF/VF have a VF token required or not by cat /sys/...

@Alex may consider this design.