[PATCH bpf-next 1/7] bpf: Allow BPF LSM programs to attach to more hooks

[Anton Protopopov]

On 26/08/31 06:42PM, Paul Moore wrote:
> On Mon, Aug 31, 2026 at 6:59 AM Anton Protopopov
> <a.s.protopopov at gmail.com> wrote:
> >
> > The BPF LSM programs are allowed to attach to LSM hooks, all of which
> > are defined in the <lsm_hook_defs.h> header file.  From BPF's point
> > of view the set of attachment points is defined in the bpf_lsm_hooks
> > BTF set. By analogy with existing code, add a new header file
> > <bpf_lsm_hook_defs.h> which will also be included in the bpf_lsm_hooks
> > BTF set.
> >
> > This change allows attaching BPF LSM programs to more functions.
> > The actual hooks are added in subsequent commits.
> >
> > Each BPF hook calls a [__weak] noinline function each time a hook is
> > reached. This may be too expensive for hot paths if a BPF program is
> > not attached. A future commit will optimize this by adding a per-hook
> > static key and inc/dec it on attach/detach. This way disabled hooks
> > will be bypassed efficiently.
> >
> > Signed-off-by: Anton Protopopov <a.s.protopopov at gmail.com>
> > ---
> >  MAINTAINERS                       |  1 +
> >  include/linux/bpf_lsm.h           | 12 ++++++++++++
> >  include/linux/bpf_lsm_hook_defs.h |  6 ++++++
> >  kernel/bpf/bpf_lsm.c              |  2 ++
> >  4 files changed, 21 insertions(+)
> >  create mode 100644 include/linux/bpf_lsm_hook_defs.h
> 
> Adding new BPF hooks in the kernel is one thing, but adding new BPF
> LSM hooks outside of the LSM framework is likely to be problematic as
> these new hooks operate disconnected from the LSM framework (callback
> and LSM kernel object state management).  We've seen bugs in the past
> caused by the BPF LSM trying to operate independently of the LSM
> framework, something like this will only make that worse.

Could you please point me to some of the bugs you mention, such that
I understand exactly what you mean? I am not really seeing how the
real LSM hooks differ from the ones added here (from BPF point of
view, and the objects it can access via kfuncs/maps). We provide the
same "sleepable", "untrusted", etc. guarantees with the new hooks,
as for normal ones.

The main reason (for now) to specifically create a new list of BPF-only LSM
hooks is (pcmoore/lsm.git/tree/README.md):

  """New LSM hooks must demonstrate their usefulness by providing a meaningful
  implementation for at least one in-kernel LSM.  The goal is to demonstrate the
  purpose and expected semantics of the hooks.  Out of tree kernel code, and pass
  through implementations, such as the BPF LSM, are not eligible for LSM hook
  reference implementations."""

And for the hooks added in this series

  a) BPF satisfies our needs, as we can precisely analyse what the
     calls are trying to do with good granularity

  b) I am not sure how to actually express this in any in-tree LSMs

Can't BPF be considered enough to demonstrate usefulness?

> 
> -- 
> paul-moore.com