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:   Fri, 09 Jun 2017 18:24:01 -0400
From:   Doug Ledford <dledford@...hat.com>
To:     Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
        Saeed Mahameed <saeedm@....mellanox.co.il>
Cc:     Ilan Tayari <ilant@...lanox.com>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        "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, 2017-06-07 at 13:21 -0600, Jason Gunthorpe wrote:
> On Wed, Jun 07, 2017 at 10:13:43PM +0300, Saeed Mahameed wrote:
> > 
> > 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 :(

Aren't the transmit/receive queues of the Ethernet netdevice on
mlx4/mlx5 hardware QPs too?  Those bypass the RDMA subsystem entirely.
 Just because something uses a QP on hardware that does *everything*
via QPs doesn't necessarily mean it must go through the RDMA subsystem.

Now, the fact that the content of the packets is basically a RoCE
packet does make things a bit fuzzier, but if their packets are
specially crafted RoCE packets that aren't really intended to be fully
RoCE spec compliant (maybe they don't support all the options as normal
RoCE QPs), then I can see hiding them from the larger RoCE portion of
the RDMA stack.

> > 
> > > 
> > > 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 a valid concern.

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

Right.  The question becomes: Does the firmware filter outgoing raw ETH
QPs such that a nefarious user could not send a crafted RoCE packet
that the bump on the wire would intercept and accept?

-- 
Doug Ledford <dledford@...hat.com>
    GPG KeyID: B826A3330E572FDD
   
Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD