Re: [PATCH bpf-next 0/2] lsm: give BPF programs a way to query locked_down state

On Tue, Aug 18, 2026 at 11:42:34AM +0200, Kumar Kartikeya Dwivedi wrote:
> On Sat Aug 15, 2026 at 1:20 PM CEST, Justin Suess wrote:
> > Howdy,
> >
> > BPF programs can attach to the locked_down LSM hook and contribute a
> > verdict, but they have never been able to ask the locked_down question
> > themselves: there is no way for a program to invoke the hook and learn
> > whether a given operation is locked down. (i.e be a caller of
> > security_locked_down rather than a consumer).
> >
> > Today the state has to be fed in out of band, for example userspace
> > reading /sys/kernel/security/lockdown and writing the result into a
> > map. That is a time-of-check/time-of-use race: a security_locked_down
> > verdict can be raised at runtime, so the cached answer can be stale
> > by the time the program acts on it.
> >
> > Add a bpf_security_locked_down() kfunc that calls
> > security_locked_down() and returns its verdict, letting LSM and
> > syscall programs query locked_down state at decision time. Out-of-range
> > reasons are rejected with -EINVAL before dispatching the hook, and the
> > kfunc is refused to programs attached to the locked_down hook itself,
> > which would recurse into the dispatch. (how the obvious recursion issue
> > is addressed).
> >
> > As this is the first pure-lsm-hook kfunc, add a new file security/lsm_kfuncs.c
> > to host it.
> >
> > This kfunc has no reliance on / relation to the Lockdown LSM, despite the
> > similar naming. It is an LSM-agnostic caller of security_locked_down, and
> > Lockdown just happens to be the only in-tree subscriber to this hook at the
> > moment.
> >
> > In fact, the test environment does not rely on CONFIG_SECURITY_LOCKDOWN at
> > all, and uses a BPF implementation of security_locked_down.
> >
> > This kfunc can cause notices to be printed with kmsg if the Lockdown LSM is
> > enabled due to this line in security/lockdown/lockdown.c:
> >
> >   pr_notice_ratelimited("Lockdown: %s: %s is restricted; see man kernel_lockdown.7\n",
> > 				                 current->comm, lockdown_reasons[what]);
> >
> > Patch 1 adds the kfunc, patch 2 the selftests. This is based on bpf-next/master, but
> > applies cleanly to the lsm tree.
> >
> 
> I don't think there is good enough justification to add this in the discussion.
> The reason you gave (dynamically disabling hibernation) also doesn't inspire
> confidence. I think figuring out some other way to achieve that is better.
>

It is really a quite terrible hack isn't it?

I am using it as part of an hid_bpf_ops program to allow disabling
hibernation on my Linux smartTV box via their proprietary remote
contro.

But you are right using it that way smells off.

I was proud of it anyway...
> If you care about knowing the state of lockdown LSM, doing
> bpf_probe_read_kernel() etc. should allow reading that state from the program.
> If you have a BPF LSM supplying a dynamic verdict in your environment, I don't
> see why you cannot use the decision procedure from the same implementation in
> other places of the LSM. I doubt you have the scenario where BPF LSM is shipped
> by someone else and your program needs access to its decisions instead.

This argument persuaded me.

Given this, I don't think the kfunc is the correct way to do what I was
trying to do anyway... so I will drop this for now since it was a trivial
patch.

Justin
> 
> Lastly, given the difficulties we've faced from the LSM maintainers, I'm not
> inclined to waste more time in explaining again why this cannot go under
> security/.
> 
> pw-bot: cr
> 
> > [...]