netdev - Re: [PATCH v3 bpf-next/net 2/5] bpf: Support bpf_setsockopt() for BPF_CGROUP_INET_SOCK

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: <aK4g640zGakSxlD9@mini-arch>
Date: Tue, 26 Aug 2025 14:02:35 -0700
From: Stanislav Fomichev <stfomichev@...il.com>
To: Kuniyuki Iwashima <kuniyu@...gle.com>
Cc: Alexei Starovoitov <ast@...nel.org>,
	Andrii Nakryiko <andrii@...nel.org>,
	Daniel Borkmann <daniel@...earbox.net>,
	Martin KaFai Lau <martin.lau@...ux.dev>,
	John Fastabend <john.fastabend@...il.com>,
	Stanislav Fomichev <sdf@...ichev.me>,
	Johannes Weiner <hannes@...xchg.org>,
	Michal Hocko <mhocko@...nel.org>,
	Roman Gushchin <roman.gushchin@...ux.dev>,
	Shakeel Butt <shakeel.butt@...ux.dev>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Neal Cardwell <ncardwell@...gle.com>,
	Willem de Bruijn <willemb@...gle.com>,
	Mina Almasry <almasrymina@...gle.com>,
	Kuniyuki Iwashima <kuni1840@...il.com>, bpf@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: [PATCH v3 bpf-next/net 2/5] bpf: Support bpf_setsockopt() for
 BPF_CGROUP_INET_SOCK_CREATE.

On 08/26, Kuniyuki Iwashima wrote:
> We will store a flag in sk->sk_memcg by bpf_setsockopt() during
> socket() or before sk->sk_memcg is set in accept().
> 
> BPF_CGROUP_INET_SOCK_CREATE is invoked by __cgroup_bpf_run_filter_sk()
> that passes a pointer to struct sock to the bpf prog as void *ctx.
> 
> But there are no bpf_func_proto for bpf_setsockopt() that receives
> the ctx as a pointer to struct sock.
> 
> Let's add a new bpf_setsockopt() variant for BPF_CGROUP_INET_SOCK_CREATE.

[..]

> Note that inet_create() is not under lock_sock().

Does anything prevent us from grabbing the lock before running
SOCK_CREATE progs? This is not the fast path, so should be ok?
Will make it easier to reason about socket options (where all paths
are locked). We do similar things for sock_addr progs in
BPF_CGROUP_RUN_SA_PROG_LOCK.