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: <CAAVpQUARxRTbmFiNE5GuO03qQAikddhT=BLcTWJVHvwK_Yq=Pg@mail.gmail.com>
Date: Tue, 26 Aug 2025 14:24:40 -0700
From: Kuniyuki Iwashima <kuniyu@...gle.com>
To: Stanislav Fomichev <stfomichev@...il.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 Tue, Aug 26, 2025 at 2:02 PM Stanislav Fomichev <stfomichev@...il.com> wrote:
>
> 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.

We can do that, but the reasoning here is exactly same with
how we allow unlocked setsockopt() for LSM hooks.  Also, SA_
prog actually needs lock_sock() to prevent sk->{addr fields} from
being changed concurrently.

---8<---
/* List of LSM hooks that trigger while the socket is _not_ locked,
 * but it's ok to call bpf_{g,s}etsockopt because the socket is still
 * in the early init phase.
 */
BTF_SET_START(bpf_lsm_unlocked_sockopt_hooks)
#ifdef CONFIG_SECURITY_NETWORK
BTF_ID(func, bpf_lsm_socket_post_create)
BTF_ID(func, bpf_lsm_socket_socketpair)
#endif
BTF_SET_END(bpf_lsm_unlocked_sockopt_hooks)
---8<---

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ