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

On 26/09/01 06:15PM, Paul Moore wrote:

On Tue, Sep 1, 2026 at 9:26 AM Anton Protopopov
[off-list ref] wrote:

quoted

On 26/08/31 06:42PM, Paul Moore wrote:

quoted

On Mon, Aug 31, 2026 at 6:59 AM Anton Protopopov
[off-list ref] wrote:

quoted

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 <redacted>
---
 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 (local)

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

quoted

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.

quoted

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