Re: [PATCH bpf-next 1/7] bpf: Make KF_TRUSTED_ARGS the default for all kfuncs

[Eduard Zingerman <eddyz87@gmail.com>]

On Wed, 2025-12-24 at 11:24 -0800, Puranjay Mohan wrote:
> Change the verifier to make trusted args the default requirement for
> all kfuncs by removing is_kfunc_trusted_args() assuming it be to always
> return true.
>
> This works because:
> 1. Context pointers (xdp_md, __sk_buff, etc.) are handled through their
>    own KF_ARG_PTR_TO_CTX case label and bypass the trusted check
> 2. Struct_ops callback arguments are already marked as PTR_TRUSTED during
>    initialization and pass is_trusted_reg()
> 3. KF_RCU kfuncs are handled separately via is_kfunc_rcu() checks at
>    call sites (always checked with || alongside is_kfunc_trusted_args)
>
> This simple change makes all kfuncs require trusted args by default
> while maintaining correct behavior for all existing special cases.

While I like the idea behind this patch, I don't think this is 100%
backwards compatible change. Not unless you check definition of every
kfunc in the kernel and add appropriate __nullable annotations,
like you do for some in patch #2.

For example, consider the following kfunc from drivers/hid/bpf/hid_bpf_dispatch.c:

  __bpf_kfunc int
  hid_bpf_hw_request(struct hid_bpf_ctx *ctx, __u8 *buf, size_t buf__sz,
                     enum hid_report_type rtype, enum hid_class_request reqtype)
          ... __hid_bpf_hw_check_params(ctx, buf, &size, rtype); ...


  static int
  __hid_bpf_hw_check_params(struct hid_bpf_ctx *ctx, __u8 *buf, size_t *buf__sz,
                            enum hid_report_type rtype)
          ...
          if (... !buf)
                  return -EINVAL;

  BTF_ID_FLAGS(func, hid_bpf_hw_request, KF_SLEEPABLE)

Currently, it is possible to pass 'buf' parameter as NULL.
In this particular case it would lead to an error code returned from
the function, but is it the case for all kfuncs in the kernel?
For some kfuncs NULL parameter might be expected as a part of a
non-error scenario.
Also, there is a question about kfuncs declared in out of tree modules.

So, I think there are two questions to be answered:
- a review of all kfuncs in the kernel checking if there are
  sufficient __nullable annotations;
- are we ready to potentially break BPF programs working with kfuncs
  defined in out-of-tree modules?
  
Wdyt?

[...]