[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHC9VhQCS-TfSL4cMfBu2GszHS8DVE05Z6FH-zPXV=EiH4ZHdg@mail.gmail.com>
Date: Mon, 7 Apr 2025 21:34:57 -0400
From: Paul Moore <paul@...l-moore.com>
To: Kuniyuki Iwashima <kuniyu@...zon.com>, selinux@...r.kernel.org,
linux-security-module@...r.kernel.org,
Casey Schaufler <casey@...aufler-ca.com>
Cc: "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>,
David Ahern <dsahern@...nel.org>, Neal Cardwell <ncardwell@...gle.com>,
Willem de Bruijn <willemb@...gle.com>, Pablo Neira Ayuso <pablo@...filter.org>,
Jozsef Kadlecsik <kadlec@...filter.org>, James Morris <jmorris@...ei.org>,
"Serge E. Hallyn" <serge@...lyn.com>, Kuniyuki Iwashima <kuni1840@...il.com>, netdev@...r.kernel.org
Subject: Re: [PATCH v1 net-next 2/4] net: Retire DCCP.
On Mon, Apr 7, 2025 at 7:19 PM Kuniyuki Iwashima <kuniyu@...zon.com> wrote:
>
> DCCP was orphaned in 2021 by commit 054c4610bd05 ("MAINTAINERS: dccp:
> move Gerrit Renker to CREDITS"), which noted that the last maintainer
> had been inactive for five years.
>
> In recent years, it has become a playground for syzbot, and most changes
> to DCCP have been odd bug fixes triggered by syzbot. Apart from that,
> the only changes have been driven by treewide or networking API updates
> or adjustments related to TCP.
>
> Thus, in 2023, we announced we would remove DCCP in 2025 via commit
> b144fcaf46d4 ("dccp: Print deprecation notice.").
>
> Since then, only one individual has contacted the netdev mailing list. [0]
>
> There is ongoing research for Multipath DCCP. The repository is hosted
> on GitHub [1], and development is not taking place through the upstream
> community. While the repository is published under the GPLv2 license,
> the scheduling part remains proprietary, with a LICENSE file [2] stating:
>
> "This is not Open Source software."
>
> The researcher mentioned a plan to address the licensing issue, upstream
> the patches, and step up as a maintainer, but there has been no further
> communication since then.
>
> Maintaining DCCP for a decade without any real users has become a burden.
>
> Therefore, it's time to remove it.
>
> Removing DCCP will also provide significant benefits to TCP. It allows
> us to freely reorganize the layout of struct inet_connection_sock, which
> is currently shared with DCCP, and optimize it to reduce the number of
> cachelines accessed in the TCP fast path.
>
> Note that we leave uAPI headers alone for userspace programs.
>
> Link: https://lore.kernel.org/netdev/20230710182253.81446-1-kuniyu@amazon.com/T/#u #[0]
> Link: https://github.com/telekom/mp-dccp #[1]
> Link: https://github.com/telekom/mp-dccp/blob/mpdccp_v03_k5.10/net/dccp/non_gpl_scheduler/LICENSE #[2]
> Signed-off-by: Kuniyuki Iwashima <kuniyu@...zon.com>
Adding the LSM and SELinux lists for obvious reasons, as well as Casey
directly since he maintains Smack and I don't see him on the To/CC
line.
For those that weren't on the original posting, the lore link is below:
https://lore.kernel.org/all/20250407231823.95927-1-kuniyu@amazon.com
> diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
> index 04a9b480885e..5665aa5e7853 100644
> --- a/security/selinux/include/classmap.h
> +++ b/security/selinux/include/classmap.h
> @@ -127,8 +127,6 @@ const struct security_class_mapping secclass_map[] = {
> { "key",
> { "view", "read", "write", "search", "link", "setattr", "create",
> NULL } },
> - { "dccp_socket",
> - { COMMON_SOCK_PERMS, "node_bind", "name_connect", NULL } },
> { "memprotect", { "mmap_zero", NULL } },
> { "peer", { "recv", NULL } },
> { "capability2", { COMMON_CAP2_PERMS, NULL } },
A quick question for the rest of the SELinux folks: the DCCP code is
going away, so we won't be performing any of the access checks listed
above, and there will be no way to get a "dccp_socket" object, but do
we want to preserve the class/perms simply to quiet the warning when
loading existing policies?
Personally I'm not too bothered by those warnings, I see them fairly
regularly for a few classes/perms on my test systems, but thought it
was worth having a quick discussion on this one since it is a bit
different.
--
paul-moore.com
Powered by blists - more mailing lists