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

[Mahe Tardy <mahe.tardy@gmail.com>]

On Mon, Jul 06, 2026 at 02:33:43PM -0700, Amery Hung wrote:
> On Mon, Jul 6, 2026 at 3:26 AM Mahe Tardy <mahe.tardy@gmail.com> 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)
> >   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.
> 
> Are these the first BPF kfuncs that invoke (attachable) security
> hooks? Some fs kfuncs seem to deliberately skip them. Can we avoid the
> limiting recursion check by skipping the security hook in
> bpf_ksock_send()? There is still security_socket_connect() in
> bpf_ksock_connect() to prevent undesired send.

FYI I found some piece of documentation around kfuncs and LSM hooks[^1],
people tried to avoid the recursion to happen in the first place.

Initially I wrote this with kernel sockets, which are not subject to LSM
hooks on the send path iirc. I migrated away from this thinking that
those "bpf sockets" should still be subject to the LSMs and not bypass
them, but we can change that or also have it partially as you mentioned
with connect but not send? Note that this would maybe change if we go
the sendto route as suggested on the other thread.

[^1]: https://docs.kernel.org/bpf/fs_kfuncs.html

> 
> >
> > 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.
> >
[...]