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

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

On Tue, Aug 04, 2026 at 09:55:44PM -0700, Song Liu wrote:
> On Tue, Aug 4, 2026 at 9:47 AM Mahe Tardy <mahe.tardy@gmail.com> wrote:
> [...]
> > +__bpf_kfunc int bpf_ksock_send(struct bpf_ksock *ks, const void *data,
> > +                              u32 data__sz)
> > +{
> > +       struct msghdr msg = {
> > +               .msg_flags = MSG_DONTWAIT,
> > +       };
> > +       struct kvec iov = {
> > +               .iov_base = (void *)data,
> > +               .iov_len = data__sz,
> > +       };
> > +       int ret;
> > +
> > +       if (!bpf_ksock_has_user_task_context())
> > +               return -EOPNOTSUPP;
> > +
> > +       /* Early check for UDP. Exact limits enforced by kernel_sendmsg(). */
> > +       if (data__sz > IP_MAX_MTU)
> > +               return -EMSGSIZE;
> > +
> > +       if (current->in_bpf_ksock_send)
> > +               return -EBUSY;
> 
> Returning EBUSY is not ideal. Can we avoid recursion by disallowing
> calling bpf_ksock_send from certain hooks? You can find examples
> check_kfunc_call() or check_special_kfunc(). This probably means
> we need to grow special_kfunc_list, which is not ideal.

This is actually a really nice feedback. I didn't know we could add a
filter per attach BTF ID. This resolves the issue that the send kfunc
calls security_socket_sendmsg so we can remove all the recursion
protection and struggles, it's rejected at verifier time.

The filter now looks like this, I'd send this in the next version:

BTF_ID_LIST_SINGLE(bpf_lsm_socket_sendmsg_id, func, bpf_lsm_socket_sendmsg)

static int bpf_ksock_kfunc_filter(const struct bpf_prog *prog, u32 kfunc_id)
{
	if (!btf_id_set8_contains(&ksock_kfunc_btf_ids, kfunc_id))
		return 0;

	if (prog->type == BPF_PROG_TYPE_SYSCALL)
		return 0;

	if (prog->type == BPF_PROG_TYPE_LSM &&
	    prog->aux->attach_btf_id != bpf_lsm_socket_sendmsg_id[0])
		return 0;

	return -EACCES;
}

I don't think I need to touch anything else. I'll adjust the tests
according to this. Thanks Song.

> 
> @Kumar, do you have strong objection that we grow special_kfunc_list
> for this use case?
> 
> Thanks,
> Song
> 
> 
> > +
> > +       current->in_bpf_ksock_send = true;
> > +       ret = kernel_sendmsg(ks->sock, &msg, &iov, 1, data__sz);
> > +       current->in_bpf_ksock_send = false;
> > +
> > +       return ret;
> > +}
> > +
> > +__bpf_kfunc_end_defs();