From: Geliang Tang <geliang@kernel.org>
To: Matthieu Baerts <matttbe@kernel.org>,
Mat Martineau <martineau@kernel.org>,
Geliang Tang <geliang@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
Neal Cardwell <ncardwell@google.com>,
Kuniyuki Iwashima <kuniyu@google.com>,
John Fastabend <john.fastabend@gmail.com>,
Sabrina Dubroca <sd@queasysnail.net>,
Hannes Reinecke <hare@suse.de>
Cc: Geliang Tang <tanggeliang@kylinos.cn>,
netdev@vger.kernel.org, mptcp@lists.linux.dev,
Gang Yan <yangang@kylinos.cn>, Zqiang <qiang.zhang@linux.dev>
Subject: [RFC net-next 00/17] MPTCP KTLS support
Date: Mon, 22 Jun 2026 18:43:20 +0800 [thread overview]
Message-ID: <cover.1782123118.git.tanggeliang@kylinos.cn> (raw)
From: Geliang Tang <tanggeliang@kylinos.cn>
Prior to this work, MPTCP did not support TLS. The two protocols
conflicted because both MPTCP and TLS use the ULP (Upper Layer
Protocol) infrastructure in the Linux kernel. ULP settings, including
TLS configuration, were disabled in MPTCP. If an application attempted
to set TLS for an MPTCP socket, the system would return an error code
indicating EOPNOTSUPP (Operation not supported).
This series adds KTLS support for MPTCP. Since no ULP is currently
attached to the MPTCP socket (msk), KTLS can be configured directly on
the msk rather than on individual subflows. This does not affect its
existing communication, and leverages HMAC-based authentication to
ensure subflow security.
RFC versions of this series have gone through many iterations on MPTCP
mailing list, mainly to address Sashiko's review comments. It is now mostly
stable.
A follow-up series will add MPTCP support to the TLS selftests
(tools/testing/selftests/net/tls.c). All existing TCP test cases have
already been verified to pass over MPTCP as well.
The primary validation use case for this work is NVMe over MPTCP with KTLS.
NVMe over TCP is a storage protocol that transports NVMe commands over TCP.
By combining it with MPTCP, multipath capabilities for storage traffic are
gained. By adding KTLS, the storage traffic is secured with encryption.
Although NVMe over MPTCP is still under active development, I have already
verified that KTLS operates correctly on top of it.
All feedback is welcome.
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/480
Co-developed-by: Gang Yan <yangang@kylinos.cn>
Signed-off-by: Gang Yan <yangang@kylinos.cn>
Co-developed-by: Zqiang <qiang.zhang@linux.dev>
Signed-off-by: Zqiang <qiang.zhang@linux.dev>
Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
Gang Yan (1):
mptcp: update mptcp_check_readable helper
Geliang Tang (16):
tls: make tls_ctx_create and update_sk_prot static
tls: factor out __tls_build_proto for mptcp support
tls: add protocol dimension to tls operation cache
mptcp: add sendmsg_locked to proto_ops
tls: use sendmsg_locked from the underlying socket
mptcp: implement peek_len for proto_ops
tls: replace tcp_inq with socket peek_len
tls: store original read_sock for non-tcp sockets
tls: introduce tls protocol ops structure
tls: use protocol ops via tls_context
mptcp: implement mptcp-specific tls protocol ops
tls: add mptcp support for sk_poll
tls: disable device offload for mptcp sockets
mptcp: implement ulp getsockopt for tls support
mptcp: implement ulp setsockopt for tls support
selftests: mptcp: connect: use espintcp for ulp test
include/net/mptcp.h | 11 +
include/net/tcp.h | 1 +
include/net/tls.h | 19 ++
net/ipv4/tcp.c | 9 +-
net/mptcp/protocol.c | 180 +++++++++++++-
net/mptcp/protocol.h | 1 +
net/mptcp/sockopt.c | 68 +++++-
net/tls/tls.h | 2 -
net/tls/tls_device.c | 10 +-
net/tls/tls_main.c | 227 +++++++++++++++---
net/tls/tls_strp.c | 35 ++-
net/tls/tls_sw.c | 10 +-
tools/testing/selftests/net/mptcp/config | 4 +
.../selftests/net/mptcp/mptcp_connect.c | 4 +-
14 files changed, 516 insertions(+), 65 deletions(-)
--
2.53.0
next reply other threads:[~2026-06-22 10:44 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-22 10:43 Geliang Tang [this message]
2026-06-22 10:43 ` [RFC net-next 01/17] tls: make tls_ctx_create and update_sk_prot static Geliang Tang
2026-06-22 10:43 ` [RFC net-next 02/17] tls: factor out __tls_build_proto for mptcp support Geliang Tang
2026-06-22 10:43 ` [RFC net-next 03/17] tls: add protocol dimension to tls operation cache Geliang Tang
2026-06-22 10:43 ` [RFC net-next 04/17] mptcp: add sendmsg_locked to proto_ops Geliang Tang
2026-06-22 10:43 ` [RFC net-next 05/17] tls: use sendmsg_locked from the underlying socket Geliang Tang
2026-06-22 10:43 ` [RFC net-next 06/17] mptcp: implement peek_len for proto_ops Geliang Tang
2026-06-22 10:43 ` [RFC net-next 07/17] tls: replace tcp_inq with socket peek_len Geliang Tang
2026-06-22 10:43 ` [RFC net-next 08/17] tls: store original read_sock for non-tcp sockets Geliang Tang
2026-06-22 10:43 ` [RFC net-next 09/17] tls: introduce tls protocol ops structure Geliang Tang
2026-06-22 10:43 ` [RFC net-next 10/17] tls: use protocol ops via tls_context Geliang Tang
2026-06-22 10:43 ` [RFC net-next 11/17] mptcp: implement mptcp-specific tls protocol ops Geliang Tang
2026-06-22 10:43 ` [RFC net-next 12/17] tls: add mptcp support for sk_poll Geliang Tang
2026-06-22 10:43 ` [RFC net-next 13/17] tls: disable device offload for mptcp sockets Geliang Tang
2026-06-22 10:43 ` [RFC net-next 14/17] mptcp: update mptcp_check_readable helper Geliang Tang
2026-06-22 10:43 ` [RFC net-next 15/17] mptcp: implement ulp getsockopt for tls support Geliang Tang
2026-06-22 10:43 ` [RFC net-next 16/17] mptcp: implement ulp setsockopt " Geliang Tang
2026-06-22 10:43 ` [RFC net-next 17/17] selftests: mptcp: connect: use espintcp for ulp test Geliang Tang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cover.1782123118.git.tanggeliang@kylinos.cn \
--to=geliang@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hare@suse.de \
--cc=horms@kernel.org \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=kuniyu@google.com \
--cc=martineau@kernel.org \
--cc=matttbe@kernel.org \
--cc=mptcp@lists.linux.dev \
--cc=ncardwell@google.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=qiang.zhang@linux.dev \
--cc=sd@queasysnail.net \
--cc=tanggeliang@kylinos.cn \
--cc=yangang@kylinos.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox