From: Jerin Jacob <jerinjacobk@gmail.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Thomas Monjalon <thomas@monjalon.net>, dpdk-dev <dev@dpdk.org>,
Jerin Jacob Kollanukkaran <jerinj@marvell.com>,
Vamsi Krishna Attunuru <vattunuru@marvell.com>,
Andrew Rybchenko <arybchenko@solarflare.com>,
Ferruh Yigit <ferruh.yigit@intel.com>,
maxime.coquelin@redhat.com,
Stephen Hemminger <stephen@networkplumber.org>,
"Richardson, Bruce" <bruce.richardson@intel.com>,
David Marchand <david.marchand@redhat.com>,
Luca Boccassi <bluca@debian.org>,
Christian Ehrhardt <christian.ehrhardt@canonical.com>,
Kevin Traynor <ktraynor@redhat.com>,
Anatoly Burakov <anatoly.burakov@intel.com>,
"Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>,
Liang-Min Wang <liang-min.wang@intel.com>,
Alexander Duyck <alexander.h.duyck@intel.com>,
Peter Xu <peterx@redhat.com>, Eric Auger <eric.auger@redhat.com>
Subject: Re: [dpdk-dev] [PATCH v1 1/1] kernel/linux: introduce vfio_pf kernel module
Date: Thu, 7 Nov 2019 10:32:12 +0530 [thread overview]
Message-ID: <CALBAE1OR7FH2mWqdqgSguTkdbs94x+22PO+yLiKdb=+pncv0Zg@mail.gmail.com> (raw)
In-Reply-To: <20191106153250.77e63a38@x1.home>
On Thu, Nov 7, 2019 at 4:03 AM Alex Williamson
<alex.williamson@redhat.com> wrote:
>
> On Thu, 31 Oct 2019 18:03:53 +0100
> Thomas Monjalon <thomas@monjalon.net> wrote:
>
> > We don't get enough attention on this topic.
> > Let me rephrase the issue and the proposals with more people Cc'ed.
> >
> > We are talking about SR-IOV VFs in VMs
> > with a PF managed on the host by DPDK.
> > The PF driver is either a (1) bifurcated (Mellanox case),
> > or (2) bound to UIO with igb_uio, or (3) bound to VFIO.
> >
> > In case 1, the PF is still managed by a kernel driver, so no issue.
> >
> > In case 2, the PF is managed by UIO.
> > There is no SR-IOV support in upstream UIO,
> > but the out-of-tree module igb_uio works.
> > However we would like to drop this legacy module from DPDK.
> > Some (most) Linux distributions do not package igb_uio anyway.
> > The other issue is that igb_uio is using physical addressing,
> > which is not acceptable with OCTEON TX2 for performance reason.
> >
> > In case 3, the PF is managed by VFIO. This is the case we want to fix.
> > VFIO does not allow to create VFs.
> > The workaround is to create VFs before binding the PF to VFIO.
> > But since Linux 4.19, VFIO forbids any SR-IOV VF management.
> > There is a security concern about allowing userspace to manage SR-IOV
> > VF messages and taking the responsibility for VFs in the guest.
> >
> > It is desired to allow the system admin deciding the security levels,
> > by adding a flag in VFIO "let me manage VFs, I know what I am doing".
> > Reference of "recent" discussion: https://lkml.org/lkml/2018/3/6/855
> > For now, there is no upstream solution merged.
> >
> > This patch is proposing a solution using an out-of-tree module.
> > In this case, the admin will decide explicitly to bind the PF to vfio_pf.
> > Unfortunately this solution won't work in environments which
> > forbid any out-of-tree module.
> > Another concern is that it looks like DPDK-only solution.
> >
> > We have an issue but we do not want to propose a half-solution
> > which would harm other projects and users.
> > So the question is:
> > Do we accept this patch as a temporary solution?
> > Or can we get an agreement soon for an upstream kernel solution?
> >
> > Thanks for reading and giving your (clear) opinion.
Thanks, Alex for the feedback.
> I'm pretty appalled that anyone would consider shipping this module and
> actually claiming that it's supported in some way. Seriously, it's
Actually DPDK already shipping with this hack using the igb_uio module for UIO.
https://git.dpdk.org/dpdk/tree/kernel/linux/igb_uio/igb_uio.c#n44.
> disturbing to see a driver that intentionally circumvents a security
> issue that we all seem to agree exists, but just hand wave that it
> doesn't apply to dpdk configurations.
Yes. There is a security issue wrt netdev VFs. That's the reason, I
was scared to
submit any patch in upstream on this front. Having said that, OVS-DPDK
kind of userland
programs would like to define the fate of the netdev VF packets of the guest
as it is vswitch application. So there is a perception change in who
is controlling the who.
> Ideas have been suggested
> upstream for for quarantining VFs generated from user owned PFs such
> that we require an opt-in to make use of them in this way. Nobody
> seems to be pursuing such ideas upstream. I don't even see upstream
> proposals to add a scary sounding module option to vfio-pci that would
> taint the kernel, but make this available. If nothing else, please
> remove the vfio name from this abomination, it has nothing to do with
> vfio other than to try to subvert the security and isolation that vfio
> attempts to provide.
Thanks for the feedback. Let's hold on accepting this patch.
We would like to have an upstream solution so that DPDK needs to only focus
on userspace.
I will work on submitting a patch for the discussion in Linux upstream.
Let see how the discussion goes, Based on the that, We can revisit
fate of this module.
> Alex
>
next prev parent reply other threads:[~2019-11-07 5:02 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-06 9:12 vattunuru
2019-09-06 9:45 ` Thomas Monjalon
2019-09-06 13:27 ` Jerin Jacob Kollanukkaran
2019-09-25 4:06 ` Vamsi Krishna Attunuru
2019-09-25 7:18 ` Andrew Rybchenko
2019-10-08 5:07 ` Vamsi Krishna Attunuru
2019-10-31 17:03 ` Thomas Monjalon
2019-11-01 11:54 ` Luca Boccassi
2019-11-01 12:12 ` Jerin Jacob
2019-11-04 11:16 ` Bruce Richardson
2019-11-05 10:09 ` Luca Boccassi
2019-11-06 22:32 ` Alex Williamson
2019-11-07 5:02 ` Jerin Jacob [this message]
2019-11-15 6:57 ` Thomas Monjalon
2019-11-15 7:01 ` Jerin Jacob
2019-10-08 15:12 ` Stephen Hemminger
2019-10-08 15:28 ` Jerin Jacob
2019-10-09 23:28 ` Stephen Hemminger
2019-10-10 6:02 ` Jerin Jacob
2019-10-13 7:20 ` Jerin Jacob
2019-10-16 11:37 ` Jerin Jacob
2019-10-23 17:08 ` Jerin Jacob
2019-10-24 11:08 ` Jerin Jacob
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALBAE1OR7FH2mWqdqgSguTkdbs94x+22PO+yLiKdb=+pncv0Zg@mail.gmail.com' \
--to=jerinjacobk@gmail.com \
--cc=alex.williamson@redhat.com \
--cc=alexander.h.duyck@intel.com \
--cc=anatoly.burakov@intel.com \
--cc=arybchenko@solarflare.com \
--cc=bluca@debian.org \
--cc=bruce.richardson@intel.com \
--cc=christian.ehrhardt@canonical.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=eric.auger@redhat.com \
--cc=ferruh.yigit@intel.com \
--cc=honnappa.nagarahalli@arm.com \
--cc=jerinj@marvell.com \
--cc=konstantin.ananyev@intel.com \
--cc=ktraynor@redhat.com \
--cc=liang-min.wang@intel.com \
--cc=maxime.coquelin@redhat.com \
--cc=peterx@redhat.com \
--cc=stephen@networkplumber.org \
--cc=thomas@monjalon.net \
--cc=vattunuru@marvell.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).