netdev - Re: [PATCH v4 for-next 00/12] Add network namespace support in the RDMA-CM

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] [day] [month] [year] [list]

Date:	Mon, 8 Jun 2015 10:53:09 -0600
From:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>
To:	Haggai Eran <haggaie@...lanox.com>
Cc:	Or Gerlitz <gerlitz.or@...il.com>,
	Doug Ledford <dledford@...hat.com>,
	Or Gerlitz <ogerlitz@...lanox.com>,
	"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
	Linux Netdev List <netdev@...r.kernel.org>,
	Liran Liss <liranl@...lanox.com>,
	Guy Shapiro <guysh@...lanox.com>,
	Shachar Raindel <raindel@...lanox.com>,
	Yotam Kenneth <yotamke@...lanox.com>
Subject: Re: [PATCH v4 for-next 00/12] Add network namespace support in the
 RDMA-CM

On Mon, Jun 08, 2015 at 10:52:34AM +0300, Haggai Eran wrote:
> On 04/06/2015 19:40, Jason Gunthorpe wrote:
> > Discussion idea: Can we actually use the netstack to process the
> > RDMA-CM packets? It looks like the netstack wants a skb to do this
> > mid-layer work, so rdma-cm would have to synthesize a skb for the CM
> > packets and pass it through netdev to apply all the transformations
> > and access the various internal states (eg from ipvlan, bonding,
> > etc). rdma-cm would have to 'catch' the skb once it is done traveling
> > and resume its normal processing. Very similar to your notion of using
> > UDP, but without any on-the-wire change.
> > 
> > This would fit in that same ingress spot I suggested adding the
> > routing lookup, instead of routing we want the full stack to have a go
> > at figuring out the final netdev.
> > 
> > This seems the most general because it will work for all the *vlan
> > type drivers, bonding, and all of the RDMA technologies. (each would
> > have a slightly different way to make the skb, but same basic idea)
> > 
> > Lots and lots of details to do that, but conceptually it seems pretty
> > solid?
> 
> The problem is that the network stack can do all sort of changes to the
> packets (like NAT), and it may be the case that the hardware can't
> reflect these changes later on when creating a QP.

Yes, I am aware of that, but there are also alot of things netdev can
do that we can realize, like netfilter rules to block packets, for
instance

Ignoring NAT is a bad choice as well, the best would be to drop on
NAT. It would be easy to detect if the netstack mangled the REQ skb
packet, for instance.

We can't track netdev after the QP is created, but totally ignoring
one thing and while re-implementing others seems like a bad idea, long
term...

> I think it would be best to stick with resolving the net_dev using
> the request parameters, and the simpler routing lookup. This way
> RDMA CM remains in control, and if the user configures routing in an
> unexpected way, it can just block the request.

As I said, I think that is fine for the immediate IB support, but when
you start talking about roce and emulating macvlan and ipvlan.. Then
it starts to look really bad. At least think it through carefully
before posting those series.

Jason
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html