Re: [PATCH bpf-next 2/6] bpf: Add ksock kfuncs

[Kuniyuki Iwashima <kuniyu@google.com>]

From: Stanislav Fomichev <sdf.kernel@gmail.com>
Date: Mon, 6 Jul 2026 14:02:39 -0700
> On 07/06, Mahe Tardy wrote:
> > On Mon, Jul 06, 2026 at 09:58:09AM -0700, Stanislav Fomichev wrote:
> > > On 07/06, Mahe Tardy wrote:
> > > > Add BPF kfuncs that allow BPF LSM programs to create and use sockets for
> > > > sending data. This provides a mechanism for BPF programs to emit
> > > > telemetry. For this first patch set, it's restricted to SOCK_DGRAM
> > > > socket types with IPPROTO_UDP protocol but could be easily extended to
> > > > SOCK_STREAM and IPPROTO_TCP in the future.
> > > > 
> > > > The API consists of six kfuncs:
> > > > 
> > > >   bpf_ksock_create()   - Create a socket (sleepable)
> > > 
> > > [..]
> > > 
> > > >   bpf_ksock_bind()     - Bind socket to local address (sleepable)
> > > >   bpf_ksock_connect()  - Connect socket to remote address (sleepable)
> > > 
> > > Since you're doing only UDP for now, maybe you don't need bind/connect? The
> > > kernel should autobind (by default) when you sendmsg over UDP socket (IIRC).
> > 
> > Yep indeed, I kinda overlooked that as I started with UDP & TCP supports
> > and mostly added the args checks. Another thing is that send is simpler
> > since only used on connected sockets, so you just pass the struct
> > bpf_ksock and data. So on one side it would simplify the current
> > UDP-only API for now by removing the kfuncs but we might need a more
> > complex send kfunc (something like sendto).
> 
> Since you were targeting bpf_netpoll_send_udp originally, maybe sendto
> is a better fit? You get the payload and the destination and you
> bpf_sendto() it? We can later move to stateful bind/connect if needed.
> 
> (mostly coming from the pow of minimizing api exposure initially, but
> not a strong preference)

+1, small start would be better.


> 
> > > 
> > > >   bpf_ksock_send()     - Send data through the socket (sleepable)
> > > >   bpf_ksock_acquire()  - Acquire a reference to a socket context
> > > >   bpf_ksock_release()  - Release a reference (cleanup via
> > > >                          queue_rcu_work since sock_release sleeps)
> > > > 
> > > > The setup kfuncs bpf_ksock_create, bpf_ksock_bind, bpf_ksock_connect,
> > > > can be called from SYSCALL programs only. While bpf_ksock_acquire,
> > > > bpf_ksock_release and bpf_ksock_send can be called from SYSCALL and LSM
> > > > programs.
> > > > 
> > > > The implementation follows the established kfunc lifecycle pattern
> > > > (create/acquire/release with refcounting, kptr map storage, dtor
> > > > registration). The kernel socket is wrapped in a refcounted bpf_ksock
> > > > struct. Cleanup is deferred via queue_rcu_work() because sock_release()
> > > > may sleep.
> > > > 
> > > > The kfuncs are only compiled when CONFIG_INET is enabled, as they
> > > > specifically support AF_INET and AF_INET6 sockets.
> > > > 
> > > > The socket operations go through the expected LSM hooks instead of
> > > > by-passing them like many kernel sockets since those are created by BPF
> > > > programs and thus system users. Thus bpf_ksock_send() kfunc, which is
> > > > exposed to LSM progs, has a re-entering protection to avoid recursion.
> > > > Also, because of the LSM checks, we prevent the use of the kfuncs from
> > > > asynchronous workqueue as the current value would then be invalid.
> > > 
> > > [..]
> > > 
> > > > A bpf_ksock_max sysctl is added to limit the maximum number of BPF
> > > > kernel sockets that may exist in each network namespace. Out of
> > > > simplicity for now, the settings is host wide but the counters are per
> > > > network namespace.
> > > 
> > > What is this guarding against? Rogue bpf programs creating too many sockets?
> > 
> > Yes. AI review raised this because users are prevented from creating too
> > many sockets by bumping against the max number of fd and this would
> > allow them to create way more sockets. I kind of agreed that having "a
> > limit" on resource creation would make sense but maybe it doesn't and we
> > can simplify this!
> 
> I believe even the kernel sockets go via lsm layer, so this enforcement
> can be done in an lsm bpf program. Seems like that should be enough?

Right, I don't think the per-netns limit is useful for CAP_BPF users.