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

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.

-- 
paul-moore.com