Re: [PATCH bpf-next 0/7] Add new way to add BPF LSM hooks

On Wed, Sep 02, 2026 at 09:31:36PM +0200, Anton Protopopov wrote:

On Wed, Sep 2, 2026 at 8:07 PM Alexei Starovoitov
[off-list ref] wrote:

quoted

On Mon Aug 31, 2026 at 4:09 AM PDT, Anton Protopopov wrote:

quoted

The BPF LSM programs are allowed to attach to LSM hooks. This enables
operators to mitigate known bugs without a need to reboot or livepatch
machines.  BPF has shown very useful to create such runtime policies.
However, many APIs and parts of kernel aren't covered by existing LSM
hooks and this would be beneficial to extend the coverage.

To simplify the process of adding new hooks this patch series enables
BPF to attach policy programs to hooks defined outside of the
official LSM list.

One of the reasons to add a new mechanism is that in order to add a
new LSM hook an implementation, at least one in-kernel LSM must be
added, such as SELinux or AppArmor, and BPF is specifically not
considered as a reference implementation [1].  This is, however, not
feasible for the use cases and capabilities covered by BPF LSMs,
which are not directly comparable to those of traditional LSMs.

This is no go.
bpf-lsm can attach to lsm hooks, but the machinery has nothing to
do with LSM. bpf-lsm is exactly the same as bpf-mod-ret.
So calling everything LSM is actively misleading and wrong.
Patch 1 starts this misleading naming convention
and then later patches add fake LSM hooks. Sorry, but no.

Got it, thank you.

Adding to this, there was the previously proposed "killswitch" mechanism
which may be closer to what you want. [1] Unsure of the current status of
this work, but it's a better idea than creating BPF-only LSM hooks... 

(like a bpf_override_return helper that doesn't care about
ALLOW_ERROR_INJECTION? unsure what would be best here)

Justin

[1] https://lore.kernel.org/all/20260508195749.1885522-1-sashal@kernel.org/ (local)

quoted

pw-bot: cr