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

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

On 26/09/03 08:16AM, Justin Suess wrote:
> On Wed, Sep 02, 2026 at 09:31:36PM +0200, Anton Protopopov wrote:
> > On Wed, Sep 2, 2026 at 8:07 PM Alexei Starovoitov
> > <alexei.starovoitov@gmail.com> wrote:
> > > On Mon Aug 31, 2026 at 4:09 AM PDT, Anton Protopopov wrote:
> > > > 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... 

Yes, thanks, I've seen it. In the proposed form it is not realistic.
I was going to discuss in my slot at lpc how we possibly can 
approach this in a more safe way, powered by BPF.

> (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/
> 
> 
> > >
> > > pw-bot: cr
> >