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

On Wed, Sep 2, 2026 at 11:20 AM Anton Protopopov
[off-list ref] wrote:

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

...

quoted

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