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  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:   Thu, 28 Apr 2022 20:39:01 -0700 (PDT)
From:   Mat Martineau <>
To:     Jakub Kicinski <>
Subject: Re: [PATCH net-next 0/6] mptcp: Path manager mode selection

On Thu, 28 Apr 2022, Jakub Kicinski wrote:

> On Wed, 27 Apr 2022 15:49:56 -0700 Mat Martineau wrote:
>> MPTCP already has an in-kernel path manager (PM) to add and remove TCP
>> subflows associated with a given MPTCP connection. This in-kernel PM has
>> been designed to handle typical server-side use cases, but is not very
>> flexible or configurable for client devices that may have more
>> complicated policies to implement.
>> This patch series from the MPTCP tree is the first step toward adding a
>> generic-netlink-based API for MPTCP path management, which a privileged
>> userspace daemon will be able to use to control subflow
>> establishment. These patches add a per-namespace sysctl to select the
>> default PM type (in-kernel or userspace) for new MPTCP sockets. New
>> self-tests confirm expected behavior when userspace PM is selected but
>> there is no daemon available to handle existing MPTCP PM events.
>> Subsequent patch series (already staged in the MPTCP tree) will add the
>> generic netlink path management API.
> Could you link to those patches, maybe? Feels a little strange to add
> this sysctl to switch to user space mode now, before we had a chance
> to judg^W review the netlink interface.

Hi Jakub -

Sure, no problem. If you'd prefer a pull request for this feature as a 
whole I could stage that.

Here's a tag (note: do not merge this as-is, the committer ids and full 
history aren't suitable) ->

The last 26 commits there cover the full userspace path manager kernel 
code, with the first 6 of those being this series.

Userspace path managers makes use of generic netlink MPTCP events that 
have already been upstream for a while, and the full series adds four 
netlink commands for userspace:

* MPTCP_PM_CMD_ANNOUNCE: advertise an address that's available for 
additional subflow connections.

* MPTCP_PM_CMD_REMOVE: revoke an advertisement

* MPTCP_PM_CMD_SUBFLOW_CREATE: initiate a new subflow on an existing MPTCP 

* MPTCP_PM_CMD_SUBFLOW_DESTROY: close a subflow on an existing MPTCP 

There's one commit for each command, each with an obvious title ("mptcp: 
netlink: Add MPTCP_PM_CMD_<name>")

> Does the pm_type switch not fit more neatly into the netlink interface
> itself?

We (on the MPTCP ML) did discuss that as a design option, and landed on 
the sysctl.

The stack can handle having no userspace PM daemon present since MPTCP 
connections can still be initiated without the PM and operate in single 
subflow mode at first. When the daemon starts up later it can manage the 
existing sockets and start announcing addresses or adding subflows. We 
wanted to avoid accidentally ending up with a mix of kernel-PM-managed and 
userspace-PM-managed sockets depending on when the daemon loaded.

Userspace PM daemons could depend on carrier policy or other complex 
dependencies, so it made sense to allow setting the sysctl early and leave 
more flexibility for launching the daemon later.

Mat Martineau

Powered by blists - more mailing lists