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

[Anton Protopopov <a.s.protopopov@gmail.com>]

On 26/09/01 06:15PM, Paul Moore wrote:
> On Tue, Sep 1, 2026 at 9:26 AM Anton Protopopov
> <a.s.protopopov@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@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@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

So, for this one patch specifically uses the same fix.

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

Thanks, this makes sense.

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

Yes, the actual code isn't, but all the building blocks are.
The BPF is just a sophisticated policy language, in which,
given, say, ethtool hooks are present, one can say "block
all ethtool ETHTOOL_TEST_CMD calls for the XXX driver" or so.

Is there any way into turning BPF first-class citizen from LSMs
point of view?

> -- 
> paul-moore.com