Re: [PATCH bpf-next v3 04/15] lsm: Add the bpf_lsm_policy_release kfunc and policy object destructor

[bot+bpf-ci@kernel.org]

[-- Attachment #1: Type: text/plain, Size: 2746 bytes --]

> Add security/bpf_lsm_kfuncs.c, the home of the kfuncs exposing LSM
> policy objects to BPF programs, with the first of them:
>
>   bpf_lsm_policy_release(object)                KF_RELEASE
>
> The kfuncs are the LSM framework's own BPF interface: there is no
> per-LSM kfunc and no intermediate security_*() layer.  Each kfunc
> walks the matching hook's implementation list and calls the one
> registered by the LSM whose lsmid the policy object carries.  Calling
> a kfunc for an LSM that is not active or has no policy object support
> fails at runtime rather than hiding the kfunc at verification time,
> so BPF program loading is independent of the boot-time LSM
> configuration.
>
> A policy object reference is meant to be handed over through a map
> kptr field, so also register a destructor for struct
> lsm_policy_object: map-held references are dropped on map teardown,
> possibly from a context that cannot sleep, which the
> policy_object_put() hook contract accounts for.  For the same reason
> the kfunc is not KF_SLEEPABLE, and the filter adds no per-kfunc rule:
> releasing a reference must be allowed wherever one can be held.  The
> filter itself is needed because BPF_PROG_TYPE_LSM and
> BPF_PROG_TYPE_SYSCALL, the two registered program types, share their
> kfunc lookup buckets with other program types.

Is the justification for the kfunc filter fully accurate?

Looking at bpf_prog_type_to_kfunc_hook() in kernel/bpf/btf.c, bucket
selection shows:

  case BPF_PROG_TYPE_TRACING:
  case BPF_PROG_TYPE_TRACEPOINT:
  case BPF_PROG_TYPE_RAW_TRACEPOINT:
  case BPF_PROG_TYPE_PERF_EVENT:
  case BPF_PROG_TYPE_LSM:
          return BTF_KFUNC_HOOK_TRACING;
  case BPF_PROG_TYPE_SYSCALL:
          return BTF_KFUNC_HOOK_SYSCALL;

BPF_PROG_TYPE_LSM does share BTF_KFUNC_HOOK_TRACING with TRACING,
TRACEPOINT, RAW_TRACEPOINT and PERF_EVENT program types, so the filter
is required for the register_btf_kfunc_id_set(BPF_PROG_TYPE_LSM, ...)
call.

However, BPF_PROG_TYPE_SYSCALL is the sole program type mapping to
BTF_KFUNC_HOOK_SYSCALL. No other program type can reach that bucket, so
the filter's SYSCALL arm simply allows the program type that already
owns the bucket.

The code itself is correct and matches the pattern used by
bpf_ksock_kfunc_filter in net/core/bpf_ksock.c, which registers for the
same two program types.

Should the changelog be narrowed to say the filter is needed for
BPF_PROG_TYPE_LSM specifically, since that's the one sharing its bucket
with other program types?


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/34398515657