netdev - Re: [net-next v2] tipc: improve throughput between nodes in netns

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:   Tue, 29 Oct 2019 17:56:08 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     hoang.h.le@...tech.com.au
Cc:     tipc-discussion@...ts.sourceforge.net, jon.maloy@...csson.com,
        maloy@...jonn.com, eric.dumazet@...il.com, ying.xue@...driver.com,
        netdev@...r.kernel.org
Subject: Re: [net-next v2] tipc: improve throughput between nodes in netns

From: Hoang Le <hoang.h.le@...tech.com.au>
Date: Tue, 29 Oct 2019 07:51:21 +0700

> Currently, TIPC transports intra-node user data messages directly
> socket to socket, hence shortcutting all the lower layers of the
> communication stack. This gives TIPC very good intra node performance,
> both regarding throughput and latency.
> 
> We now introduce a similar mechanism for TIPC data traffic across
> network namespaces located in the same kernel. On the send path, the
> call chain is as always accompanied by the sending node's network name
> space pointer. However, once we have reliably established that the
> receiving node is represented by a namespace on the same host, we just
> replace the namespace pointer with the receiving node/namespace's
> ditto, and follow the regular socket receive patch though the receiving
> node. This technique gives us a throughput similar to the node internal
> throughput, several times larger than if we let the traffic go though
> the full network stacks. As a comparison, max throughput for 64k
> messages is four times larger than TCP throughput for the same type of
> traffic.
> 
> To meet any security concerns, the following should be noted.
 ...
> Regarding traceability, we should notice that since commit 6c9081a3915d
> ("tipc: add loopback device tracking") it is possible to follow the node
> internal packet flow by just activating tcpdump on the loopback
> interface. This will be true even for this mechanism; by activating
> tcpdump on the involved nodes' loopback interfaces their inter-name
> space messaging can easily be tracked.
> 
> v2:
> - update 'net' pointer when node left/rejoined
> v3:
> - grab read/write lock when using node ref obj
> v4:
> - clone traffics between netns to loopback
> 
> Suggested-by: Jon Maloy <jon.maloy@...csson.com>
> Acked-by: Jon Maloy <jon.maloy@...csson.com>
> Signed-off-by: Hoang Le <hoang.h.le@...tech.com.au>

Applied to net-next.