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

[Paul Moore]

On Wed, Sep 2, 2026 at 11:20 AM Anton Protopopov
<a.s.protopopov at gmail.com> wrote:
> On 26/09/01 06:15PM, Paul Moore wrote:

...

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

As I said earlier, the important part is in-tree vs out-of-tree code.
We are not going to add new LSM hooks only for code that lives outside
the kernel sources, regardless of whether that code is written in C,
Rust, or BPF.

-- 
paul-moore.com