netdev - Re: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova

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:   Wed, 7 Jun 2017 13:21:32 -0600
From:   Jason Gunthorpe <jgunthorpe@...idianresearch.com>
To:     Saeed Mahameed <saeedm@....mellanox.co.il>
Cc:     Ilan Tayari <ilant@...lanox.com>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Doug Ledford <dledford@...hat.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
        "jsorensen@...com" <jsorensen@...com>,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        "linux-fpga@...r.kernel.org" <linux-fpga@...r.kernel.org>,
        Alan Tull <atull@...nsource.altera.com>,
        "yi1.li@...ux.intel.com" <yi1.li@...ux.intel.com>,
        Boris Pismenny <borisp@...lanox.com>
Subject: Re: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova

On Wed, Jun 07, 2017 at 10:13:43PM +0300, Saeed Mahameed wrote:
> On Wed, Jun 7, 2017 at 6:48 PM, Jason Gunthorpe
> <jgunthorpe@...idianresearch.com> wrote:
> > On Wed, Jun 07, 2017 at 07:16:42AM +0300, Saeed Mahameed wrote:
> >> On Tue, Jun 6, 2017 at 7:17 PM, Jason Gunthorpe
> >> <jgunthorpe@...idianresearch.com> wrote:
> >> > On Tue, Jun 06, 2017 at 06:52:15AM +0000, Ilan Tayari wrote:
> >> >
> >> >> So neither the host stack nor the network are aware of them.
> >> >> They exist momentarily only on the internal traces on the board and not
> >> >> anywhere else.
> >> >
> >> > Is that really true? If you are creating rocee QPs' then the RDMA
> >> > stack sees this stuff and now we have buried a RDMA ULP inside an
> >> > ethernet driver which seems really wonky..
> >>
> >> It is not an ethernet driver, mlx5_core provides both RDMA and
> >> ethernet interfaces to both mlx5_ib and the mlx5e netdevice.
> >>
> >> so it is perfectly capable of creating QPs on its own, after all it is
> >> the one creating QPs for the RDMA stack :).
> >>
> >> rdma_create_qp->mlx5_ib_create_qp->mlx5_core_create_qp.
> >
> > Wait, so you built a RDMA ULP inside your driver without using the
> > RDMA API?
> >
> 
> No !!
> I am just showing you that the ib_core eventually will end up calling
> mlx5_core to create a QP.
> so mlx5_core can create the QP it self since it is the one eventually
> creating QPs.
> we just call mlx5_core_create_qp directly.

Which is building a RDMA ULP inside a driver without using the core
code :(

> > This keep getting more ugly :(
> >
> > What about security? What if user space sends some raw packets to the
> > FPGA - can it reprogram the ISPEC settings or worse?
> >
> 
> No such thing. This QP is only for internal driver/HW communications,
> as it is faster from the existing command interface.
> it is not meant to be exposed for any raw user space usages at all,
> without proper standard API adapter of course.

I'm not asking about the QP, I'm asking what happens after the NIC
part. You use ROCE packets to control the FPGA. What prevents
userspace from forcibly constructing roce packets and sending them to
the FPGA. How does the FPGA know for certain the packet came from the
kernel QP and not someplace else.

This is especially true for mlx nics as there are many raw packet
bypass mechanisms available to userspace.

Jason