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

[Paul Moore]

On Tue, Sep 1, 2026 at 9:26 AM Anton Protopopov
<a.s.protopopov at gmail.com> wrote:
> 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?

The latest that I'm aware of was a few months ago:

https://lore.kernel.org/bpf/20260628201103.3624525-1-mattbobrowski@google.com

> 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).

The existing LSM hooks, LSM security blobs (the 'void *security'
fields present in many kernel objects), and individual LSM callbacks
are managed by the LSM framework whereas the functions you are
proposing are not.  This is important because the LSM framework
enables/disables individual LSMs at boot time which impacts both the
executed LSM callbacks and the security blob allocations.
Implementing "hooks" that operate outside the LSM framework can cause
unexpected user behavior and potentially destabilize the kernel,
leading to a system crash.

We require all LSMs (Landlock, Smack, AppArmor, SELinux, etc.) to go
through the LSM framework, the BPF LSM is no exception to this rule.
If you want to add additional BPF program call sites beyond what the
LSM framework provides, please implement them outside of the BPF LSM;
there is plenty of precendence for that already.

> 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?

The core issue has little to do with BPF, it has everything to do with
in-tree vs out-of-tree code.  The BPF LSM is explicitly mentioned as a
"pass through" because some have argued that the BPF LSM is in-tree,
and while the basic BPF enablement is in-tree, the actual LSM code
that is executed has thus far always been out-of-tree.

-- 
paul-moore.com