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

On Sun, Aug 09, 2026 at 03:18:21PM -0400, Paul Moore wrote:
> On Fri, Aug 7, 2026 at 6:00 PM Justin Suess <[email protected]> wrote:
> > On Fri, Aug 07, 2026 at 04:36:20PM -0400, Paul Moore wrote:
> > > On Wed, Aug 5, 2026 at 8:32 PM Justin Suess <[email protected]> wrote:
> > > > On Wed, Aug 05, 2026 at 06:51:56PM -0400, Paul Moore wrote:
> > > > > On Wed, Aug 5, 2026 at 5:37 PM Justin Suess <[email protected]> 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 <[email protected]> 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
> > > >
> > > > I'm 100% on board with the no calling directly into individual LSMs part.
> > > >
> > > > > 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).
> > > >
> > > > The intention is the opposite. The point of the separate directory is
> > > > that the kfuncs can never call into an individual LSM, they only get
> > > > the LSM framework API in <linux/security.h>.
> > > >
> > > > Every kfunc is a thin wrapper over the generic policy kptr hooks:
> > > >
> > > >     bpf_landlock_get_ruleset_from_fd()
> > > >       -> security_policy_kptr_from_fd(LSM_ID_LANDLOCK, ...)
> > > >         -> Landlock's hook implementation
> > > >
> > > > So kfunc -> generic lsm hook -> individual LSM, same as any other
> > > > caller in the kernel.
> > >
> > > Not exactly.  That "bpf_*landlock*_XXX" kfuncs are a move away from an
> > > LSM agnostic API and not something we currently do in the kernel.
> > > Some will, and have, argued that this is more akin to the Landlock
> > > syscalls, but I see (at least) two problems with that comparison: the
> > > kfuncs being presented aren't syscalls, they are cross-subsystem
> > > kernel function calls; the Landlock syscalls were created in a
> > I see the argument for normal in-tree kernel interfaces.
> >
> > Unlike normal kernel interfaces, kfuncs:
> >
> > 1. Can exist without in-tree callers.
> 
> Yes, although I'm not sure how relevant that is to our discussion.  I
> can say that it isn't relevant to my decisions.
> 
> > 2. Are explicitly allowed to change or be removed at any time [1].
> 
> FWIW, the LSM hooks can be changed or removed at any time as well.
> For obvious reasons we try to avoid churn where possible, but there
> are plenty of cases where hooks have been modified, removed,
> relocated, etc. (some without our explicit permission, but that's
> another issue for another time).
> 
> > 3. Can't break builds or other in-tree subsystems when they do.
> 
> Of course.  Rule #1 of any kernel subsystem is don't break the build :)
> 
> > This isn't hypothetical: the entire KF_KPTR_GET class
> > (bpf_task_kptr_get(), bpf_cgroup_kptr_get(), the flag itself) was
> > removed and replaced with a better abstraction within about a year
> > of introduction.
> >
> > If Landlock (or any LSM) dies, there's zero uapi/in-tree cost to
> > removing the kfuncs, unlike syscalls which are burned into the uapi
> > forever, or ones with in-tree callers where we can break builds.
> >
> > I argue that the transient, low-commitment nature of kfuncs mitigates
> > maintainability issues that arise from lsm-specific interfaces with
> > in-tree callers. (which we are both opposed to).
> 
> Sadly, the current situation between the BPF and LSM devs is not good,
> which means any discussion around LSM kfuncs has a good chance of
> turning ugly and something that should be relatively easy to maintain
> is likely to turn into a significant headache.  To be clear, this
> doesn't mean I'm opposed to LSM kfuncs, I just don't agree that they
> are "low-commitment" at this point in time or in the foreseeable
> future.
> 
> > To avoid strawman style arguments, I ask what you would see as
> > an alternative interface?
> 
> As I've mentioned a couple of times now, you need to grant me the time
> to properly review your existing patches before I can comment in
> detail on the interface.  You've been quick to post with new thoughts,
> ideas, arguments, etc., which is fine, but replying to them steals my
> time away from the very patchset you want me to review ;)
> 
> It's up to you how you want to handle things, but my suggestion would
> be to pause some of these thoughts until I've had a chance to review
> your patchset in detail; then we can have a better discussion.
>
Apologies! I appreciate the engagement thus far, it's been helpful even
if it's not 100% agreement. (wouldn't be interesting if I don't learn
anything, or go back to drawing board).

Especially with merge window upcoming I am sure everyone is busy.

Justin
> -- 
> paul-moore.com