linux-kernel - Re: [PATCH v4] net: fully namespace net.core.{r,w}mem

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4e7227ef-a1d6-409f-a21b-5b1f26cf52b7@redhat.com>
Date: Thu, 24 Apr 2025 13:04:21 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Danny Lin <danny@...stack.dev>, Matteo Croce <teknoraver@...a.com>,
 "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, Simon Horman <horms@...nel.org>,
 David Ahern <dsahern@...nel.org>, netdev@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4] net: fully namespace net.core.{r,w}mem_{default,max}
 sysctls

On 4/18/25 9:00 AM, Danny Lin wrote:
> This builds on commit 19249c0724f2 ("net: make net.core.{r,w}mem_{default,max} namespaced")
> by adding support for writing the sysctls from within net namespaces,
> rather than only reading the values that were set in init_net. These are
> relatively commonly-used sysctls, so programs may try to set them without
> knowing that they're in a container. It can be surprising for such attempts
> to fail with EACCES.
> 
> Unlike other net sysctls that were converted to namespaced ones, many
> systems have a sysctl.conf (or other configs) that globally write to
> net.core.rmem_default on boot and expect the value to propagate to
> containers, and programs running in containers may depend on the increased
> buffer sizes in order to work properly. This means that namespacing the
> sysctls and using the kernel default values in each new netns would break
> existing workloads.
> 
> As a compromise, inherit the initial net.core.*mem_* values from the
> current process' netns when creating a new netns. This is not standard
> behavior for most netns sysctls, but it avoids breaking existing workloads.

AFAICS leveraging the above and any protocol without memory accounting
(e.g. UDP for tx) child netns could use an "unlimited" amount of kernel
memory. I'm wondering if it would be safer to limit, for child netns,
the maximum value to the corresponding initns one.

/P