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

On Thu Aug 6, 2026 at 7:21 PM CEST, Mahe Tardy wrote:
> On Tue, Aug 04, 2026 at 09:55:44PM -0700, Song Liu wrote:
>> On Tue, Aug 4, 2026 at 9:47 AM Mahe Tardy <[email protected]> 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.
>

Yep, using a kfunc filter should be enough.

>>
>> @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();