Re: [PATCH bpf-next 00/13] BPF interface for applying Landlock rulesets

[Paul Moore]

On Wed, Aug 5, 2026 at 5:37 PM Justin Suess <utilityemal77@xxxxxxxxx> wrote:
> On Fri, Jul 31, 2026 at 04:30:39PM -0400, Paul Moore wrote:
> > On Thu, Jul 30, 2026 at 10:21 PM Justin Suess <utilityemal77@xxxxxxxxx> wrote:
> > [...]
> > As you may, or may not have seen, there is currently an ongoing debate
> > regarding the location of LSM kfuncs that will impact this patchset.
> > Sadly, we don't appear to be approaching an agreement on this issue
> > which introduces some additional risk to this patchset.  We'll have to
> > see how that ends up, but I just wanted you to be aware of the
> > situation.
>
> Quick aside question: Would security/bpf/ be a better place for these
> type of kfuncs?
>
> security/bpf/bpf_lsm_kfuncs.c could be for LSM framework kfuncs,
> and each LSM could maintain their own security/bpf/<lsm>_kfuncs.c
> for kfuncs dealing with lsm-specific types.

This gets back to the other issue in the patchset that we've
discussed: general LSM interfaces vs Landlock specific interfaces.
There are plenty of reasons why we don't support the kernel calling
directly into individual LSMs, and from my perspective this is another
instance of that.  Here it just happens to be that the kernel caller
was written in BPF and not C (or Rust for that matter).

-- 
paul-moore.com