[RFC net-next 00/17] MPTCP KTLS support

Geliang Tang posted 17 patches 1 week, 5 days ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/multipath-tcp/mptcp_net-next tags/patchew/cover.1782123118.git.tanggeliang@kylinos.cn
There is a newer version of this series
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(-)
[RFC net-next 00/17] MPTCP KTLS support
Posted by Geliang Tang 1 week, 5 days ago
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
Re: [RFC net-next 00/17] MPTCP KTLS support
Posted by MPTCP CI 1 week, 5 days ago
Hi Geliang,

Thank you for your modifications, that's great!

Our CI did some validations and here is its report:

- KVM Validation: normal (except selftest_mptcp_join): Success! ✅
- KVM Validation: normal (only selftest_mptcp_join): Success! ✅
- KVM Validation: debug (except selftest_mptcp_join): Notice: Call Traces at boot time, rebooted and continued ⚠️ 
- KVM Validation: debug (only selftest_mptcp_join): Notice: Call Traces at boot time, rebooted and continued ⚠️ 
- KVM Validation: btf-normal (only bpftest_all): Success! ✅
- KVM Validation: btf-debug (only bpftest_all): Notice: Call Traces at boot time, rebooted and continued ⚠️ 
- Task: https://github.com/multipath-tcp/mptcp_net-next/actions/runs/27948260475

Initiator: Patchew Applier
Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/4fba43978071
Patchwork: https://patchwork.kernel.org/project/mptcp/list/?series=1114686


If there are some issues, you can reproduce them using the same environment as
the one used by the CI thanks to a docker image, e.g.:

    $ cd [kernel source code]
    $ docker run -v "${PWD}:${PWD}:rw" -w "${PWD}" --privileged --rm -it \
        --pull always mptcp/mptcp-upstream-virtme-docker:latest \
        auto-normal

For more details:

    https://github.com/multipath-tcp/mptcp-upstream-virtme-docker


Please note that despite all the efforts that have been already done to have a
stable tests suite when executed on a public CI like here, it is possible some
reported issues are not due to your modifications. Still, do not hesitate to
help us improve that ;-)

Cheers,
MPTCP GH Action bot
Bot operated by Matthieu Baerts (NGI0 Core)
Re: [RFC net-next 00/17] MPTCP KTLS support
Posted by Jakub Kicinski 1 week, 5 days ago
On Mon, 22 Jun 2026 18:43:20 +0800 Geliang Tang wrote:
> Subject: [RFC net-next 00/17] MPTCP KTLS support

Please no. We have a ton of unfixed bugs and may have to revert some of
the features we dropped back in. I'd prefer to avoid large new bug
surfaces until we reach an LTS release.
Re: [RFC net-next 00/17] MPTCP KTLS support
Posted by Geliang Tang 1 week, 1 day ago
On Mon, 2026-06-22 at 09:00 -0700, Jakub Kicinski wrote:
> On Mon, 22 Jun 2026 18:43:20 +0800 Geliang Tang wrote:
> > Subject: [RFC net-next 00/17] MPTCP KTLS support
> 
> Please no. We have a ton of unfixed bugs and may have to revert some
> of
> the features we dropped back in. I'd prefer to avoid large new bug
> surfaces until we reach an LTS release.

Sure, I can wait. During this time, I'll go over the implementation
more carefully to make sure there are no issues on the MPTCP side.

Thanks,
-Geliang
Re: [RFC net-next 00/17] MPTCP KTLS support
Posted by Jakub Kicinski 1 week, 1 day ago
On Fri, 26 Jun 2026 15:56:53 +0800 Geliang Tang wrote:
> On Mon, 2026-06-22 at 09:00 -0700, Jakub Kicinski wrote:
> > On Mon, 22 Jun 2026 18:43:20 +0800 Geliang Tang wrote:  
> > > Subject: [RFC net-next 00/17] MPTCP KTLS support  
> > 
> > Please no. We have a ton of unfixed bugs and may have to revert some
> > of
> > the features we dropped back in. I'd prefer to avoid large new bug
> > surfaces until we reach an LTS release.  
> 
> Sure, I can wait. During this time, I'll go over the implementation
> more carefully to make sure there are no issues on the MPTCP side.

The two things that I'd be most interested in understanding better are
1) perf impact on all the pointer chasing and indirect calls you're
   adding
2) what's your plan on implementing HW offload? I understand that _you_
   may not care, but if you follow the ML you'll discover that sooner
   or later some well meaning person will slop code such support.
   We have pretty solid (by kernel standards) documentation for the
   offload. Please read if you haven't already. And then you should
   hopefully realize the huge issue with the layering you chose...
Re: [RFC net-next 00/17] MPTCP KTLS support
Posted by Cong Wang 1 week, 2 days ago
On Mon, Jun 22, 2026 at 09:00:59AM -0700, Jakub Kicinski wrote:
> On Mon, 22 Jun 2026 18:43:20 +0800 Geliang Tang wrote:
> > Subject: [RFC net-next 00/17] MPTCP KTLS support
> 
> Please no. We have a ton of unfixed bugs and may have to revert some of
> the features we dropped back in. I'd prefer to avoid large new bug
> surfaces until we reach an LTS release.

Is this specifically for kTLS? Or the whole networking subsystem?

Asking because if it is the latter you probably want to announce this
new rule offically and update Documentation/process/maintainer-netdev.rst

Regards,
Cong