netdev - Re: [RFC] current devlink extension plan for NICs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 23 Mar 2020 19:06:05 -0300
From:   Jason Gunthorpe <jgg@...pe.ca>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Jiri Pirko <jiri@...nulli.us>, netdev@...r.kernel.org,
        davem@...emloft.net, parav@...lanox.com, yuvalav@...lanox.com,
        saeedm@...lanox.com, leon@...nel.org,
        andrew.gospodarek@...adcom.com, michael.chan@...adcom.com,
        moshe@...lanox.com, ayal@...lanox.com, eranbe@...lanox.com,
        vladbu@...lanox.com, kliteyn@...lanox.com, dchickles@...vell.com,
        sburla@...vell.com, fmanlunas@...vell.com, tariqt@...lanox.com,
        oss-drivers@...ronome.com, snelson@...sando.io,
        drivers@...sando.io, aelior@...vell.com,
        GR-everest-linux-l2@...vell.com, grygorii.strashko@...com,
        mlxsw@...lanox.com, idosch@...lanox.com, markz@...lanox.com,
        jacob.e.keller@...el.com, valex@...lanox.com,
        linyunsheng@...wei.com, lihong.yang@...el.com,
        vikas.gupta@...adcom.com, magnus.karlsson@...el.com
Subject: Re: [RFC] current devlink extension plan for NICs

On Mon, Mar 23, 2020 at 12:21:23PM -0700, Jakub Kicinski wrote:
> > >I see so you want the creation to be controlled by the same entity that
> > >controls the eswitch..
> > >
> > >To me the creation should be on the side that actually needs/will use
> > >the new port. And if it's not eswitch manager then eswitch manager
> > >needs to ack it.  
> > 
> > Hmm. The question is, is it worth to complicate things in this way?
> > I don't know. I see a lot of potential misunderstandings :/
> 
> I'd see requesting SFs over devlink/sysfs as simplification, if
> anything.

We looked at it for a while, working the communication such that the
'untrusted' side could request a port be created with certain
parameters and the 'secure eswitch' could know those parameters to
authorize and wire it up was super complicated and very hard to do
without races.

Since it is a security sensitive operation it seems like a much more
secure design to have the secure side do all the creation and present
the fully operational object to the insecure side.

To draw a parallel to qemu & kvm, the untrusted guest VM can't request
that qemu create a virtio-net for it. Those are always hot plugged in
by the secure side. Same flow here.

> > >The precedence is probably not a strong argument, but that'd be the
> > >same way VFs work.. I don't think you can change how VFs work, right?  
> > 
> > You can't, but since the VF model is not optimal as it turned out, do we
> > want to stick with it for the SFs too?
> 
> The VF model is not optimal in what sense? I thought the main reason
> for SFs is that they are significantly more light weight on Si side.

Not entirely really, the biggest reason for SF is because VF have to
be pr-eallocated and have a number limited by PCI.

The VF model is poor because the VF is just a dummy stub until the
representor/eswitch side is fully configured. There is no way for the
Linux driver to know if the VF is operational or not, so we get weird
artifacts where we sometimes bind a driver to a VF (and get a
non-working ethXX) and sometimes we don't. 

The only reason it is like this is because of how SRIOV requires
everything to be preallocated.

The SFs can't even exist until they are configured, so there is no
state where a driver is connected to an inoperative SF.

So it would be nice if VF and SF had the same flow, the SF flow is
better, lets fix the VF flow to match it.

Jason