netdev - Re: [PATCH net-next 0/6] mptcp: Path manager mode selection

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

Message-ID: <23ff3b49-2563-1874-fa35-3af55d3088e7@linux.intel.com>
Date:   Thu, 28 Apr 2022 20:39:01 -0700 (PDT)
From:   Mat Martineau <mathew.j.martineau@...ux.intel.com>
To:     Jakub Kicinski <kuba@...nel.org>
cc:     netdev@...r.kernel.org, davem@...emloft.net, pabeni@...hat.com,
        matthieu.baerts@...sares.net, mptcp@...ts.linux.dev
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) -> 
https://github.com/multipath-tcp/mptcp_net-next/commits/netdev-review-userspace-path-manager

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 
connection

* MPTCP_PM_CMD_SUBFLOW_DESTROY: close a subflow on an existing MPTCP 
connection

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
Intel