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.

Justin

Justin Suess (2):
  lsm: add bpf_security_locked_down() kfunc
  selftests/bpf: Test bpf_security_locked_down kfunc

 security/Makefile                             |  1 +
 security/lsm_kfuncs.c                         | 84 +++++++++++++++++++
 .../selftests/bpf/prog_tests/lsm_kfuncs.c     | 28 +++++++
 .../testing/selftests/bpf/progs/lsm_kfuncs.c  | 34 ++++++++
 .../selftests/bpf/progs/lsm_kfuncs_fail.c     | 26 ++++++
 5 files changed, 173 insertions(+)
 create mode 100644 security/lsm_kfuncs.c
 create mode 100644 tools/testing/selftests/bpf/prog_tests/lsm_kfuncs.c
 create mode 100644 tools/testing/selftests/bpf/progs/lsm_kfuncs.c
 create mode 100644 tools/testing/selftests/bpf/progs/lsm_kfuncs_fail.c


base-commit: d82ebfc685c91e7f5623a8be949da1ddb767420b
-- 
2.54.0

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.

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.

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

> [...]

On Tue, Aug 18, 2026 at 5:43 AM Kumar Kartikeya Dwivedi
<memxor@gmail.com> wrote:
>
>
> 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/.
>

I'm still going to send v7 of bpf_init_inode_xattr series, even though
it's a stalemate. Haven't yet decided where it'll live in v7, I'm
inclined to leave it where it was (in fs/) since one side will NAK it
wherever it lives. We can record NAKs and take it from there.

Just wanted to state this for least surprise when v7 does come out,
which will be soon.

Thanks,
David

On Tue, Aug 18, 2026 at 1:42 PM David Windsor <dwindsor@gmail.com> wrote:
> On Tue, Aug 18, 2026 at 5:43 AM Kumar Kartikeya Dwivedi
> <memxor@gmail.com> wrote:
> >
> >
> > 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/.
> >
>
> I'm still going to send v7 of bpf_init_inode_xattr series, even though
> it's a stalemate. Haven't yet decided where it'll live in v7, I'm
> inclined to leave it where it was (in fs/) since one side will NAK it
> wherever it lives. We can record NAKs and take it from there.

As a FYI, I'm not going to ACK any of the LSM changes with the kfunc
in security/bpf_lsm_kfuncs.c.

-- 
paul-moore.com

On Tue, Aug 18, 2026 at 3:48 PM Paul Moore <paul@paul-moore.com> wrote:
>
> On Tue, Aug 18, 2026 at 1:42 PM David Windsor <dwindsor@gmail.com> wrote:
> > On Tue, Aug 18, 2026 at 5:43 AM Kumar Kartikeya Dwivedi
> > <memxor@gmail.com> wrote:
> > >
> > >
> > > 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/.
> > >
> >
> > I'm still going to send v7 of bpf_init_inode_xattr series, even though
> > it's a stalemate. Haven't yet decided where it'll live in v7, I'm
> > inclined to leave it where it was (in fs/) since one side will NAK it
> > wherever it lives. We can record NAKs and take it from there.
>
> As a FYI, I'm not going to ACK any of the LSM changes with the kfunc
> in security/bpf_lsm_kfuncs.c.
>

Hmm, even if it lands in security/ you'd not ACK it? I thought what
we'd settled on as acceptable from your end was placing it in
security/, then having a broader discussion about the rest of the fs
kfuncs? Just trying to understand everyone's position.

On Tue, Aug 18, 2026 at 4:16 PM David Windsor <dwindsor@gmail.com> wrote:
> On Tue, Aug 18, 2026 at 3:48 PM Paul Moore <paul@paul-moore.com> wrote:
> > On Tue, Aug 18, 2026 at 1:42 PM David Windsor <dwindsor@gmail.com> wrote:
> > > On Tue, Aug 18, 2026 at 5:43 AM Kumar Kartikeya Dwivedi
> > > <memxor@gmail.com> wrote:
> > > >
> > > >
> > > > 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/.
> > > >
> > >
> > > I'm still going to send v7 of bpf_init_inode_xattr series, even though
> > > it's a stalemate. Haven't yet decided where it'll live in v7, I'm
> > > inclined to leave it where it was (in fs/) since one side will NAK it
> > > wherever it lives. We can record NAKs and take it from there.
> >
> > As a FYI, I'm not going to ACK any of the LSM changes with the kfunc
> > in security/bpf_lsm_kfuncs.c.
>
> Hmm, even if it lands in security/ you'd not ACK it?

Bah, a typo on my part, my apologies!  What I had meant to say was
that I'm not going to ACK any of the LSM changes with the kfunc *not*
in security/bpf_lsm_kfuncs.c.  Sorry for the confusion.

-- 
paul-moore.com

On Tue, Aug 18, 2026 at 4:33 PM Paul Moore <paul@paul-moore.com> wrote:
>
> On Tue, Aug 18, 2026 at 4:16 PM David Windsor <dwindsor@gmail.com> wrote:
> > On Tue, Aug 18, 2026 at 3:48 PM Paul Moore <paul@paul-moore.com> wrote:
> > > On Tue, Aug 18, 2026 at 1:42 PM David Windsor <dwindsor@gmail.com> wrote:
> > > > On Tue, Aug 18, 2026 at 5:43 AM Kumar Kartikeya Dwivedi
> > > > <memxor@gmail.com> wrote:
> > > > >
> > > > >
> > > > > 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/.
> > > > >
> > > >
> > > > I'm still going to send v7 of bpf_init_inode_xattr series, even though
> > > > it's a stalemate. Haven't yet decided where it'll live in v7, I'm
> > > > inclined to leave it where it was (in fs/) since one side will NAK it
> > > > wherever it lives. We can record NAKs and take it from there.
> > >
> > > As a FYI, I'm not going to ACK any of the LSM changes with the kfunc
> > > in security/bpf_lsm_kfuncs.c.
> >
> > Hmm, even if it lands in security/ you'd not ACK it?
>
> Bah, a typo on my part, my apologies!  What I had meant to say was
> that I'm not going to ACK any of the LSM changes with the kfunc *not*
> in security/bpf_lsm_kfuncs.c.  Sorry for the confusion.
>

Makes sense, thanks. I'll send it in the next week most likely.

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:
> 
> 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.
> 
(I've found a workaround with tracepoints that removes the need for this
series. Thank you anyway)
> 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/.
>
Without wanting to rehash this issue,

Both LSM and BPF maintainers, some cc'd in the thread, have worked with me as a
new contributor through my mistakes and volunteered their time, expertise, and effort.
I cannot appreciate it enough.

Clearly, great talent and commitment to making the kernel better lives on both sides of the fence.
There's also no question the whole kernel would benefit from better communication between these
awesome subsystems.

I don't mean to admonish anyone or assign fault. Debates happen, things get heated,
it's what happens. But the fact that multiple series are stalled on this because BPF/LSM
don't trust each other enough to have shared code ownership implies the current process
is broken. This isn't the first instance of this breakdown either. It hurts new
contributors caught in the crossfire, maintainers who have to tiptoe around this drama, and 
kernel users.

If anyone is willing: I'd like to set the debates aside and discuss in good faith how we can
establish a better process for LSM/BPF review, testing, and integration. So we can steer this
conversation to the technical side, which is where actual work happens.

That could be an LSM/BPF integration branch, or Documentation/, or something else, or
meeting up at a conference and having some beers together.

Kind Regards,
Justin

> pw-bot: cr
> 
> > [...]

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
> 
> > [...]

+cc Nicolas

On 8/15/2026 7:20 PM, 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.

Adding the bpf_security_locked_down() kfunc does not actually solve the
TOCTOU issue you mentioned. Even after bpf_security_locked_down() is
called, userspace can still change the lockdown state via /sys/kernel/
security/lockdown.

I fail to see the necessity for a BPF program to know whether a specific
operation is locked down. The test case provided in patch 2 does not
clearly demonstrate a scenario where this is required. In my view, the
verdict should happen exactly where security_locked_down() is currently 
invoked.

Furthermore, based on the current implementation of Lockdown, integrity
is the prerequisite for confidentiality. It is designed to be coarse-
grained and does not support per-operation lockdown. The fact that LSM
BPF can already hook into locked_down seems to violate this foundational
model, this is is analogous to the bitmap implementation [1], I’m
considering whether we should restrict BPF from attaching to the
locked_down hook. Nicolas, what are your thoughts on this?

[1] 
https://lore.kernel.org/all/20250728111517.134116-1-nik.borisov@suse.com/

> 
> 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.
> 
> Justin
> 
> Justin Suess (2):
>    lsm: add bpf_security_locked_down() kfunc
>    selftests/bpf: Test bpf_security_locked_down kfunc
> 
>   security/Makefile                             |  1 +
>   security/lsm_kfuncs.c                         | 84 +++++++++++++++++++
>   .../selftests/bpf/prog_tests/lsm_kfuncs.c     | 28 +++++++
>   .../testing/selftests/bpf/progs/lsm_kfuncs.c  | 34 ++++++++
>   .../selftests/bpf/progs/lsm_kfuncs_fail.c     | 26 ++++++
>   5 files changed, 173 insertions(+)
>   create mode 100644 security/lsm_kfuncs.c
>   create mode 100644 tools/testing/selftests/bpf/prog_tests/lsm_kfuncs.c
>   create mode 100644 tools/testing/selftests/bpf/progs/lsm_kfuncs.c
>   create mode 100644 tools/testing/selftests/bpf/progs/lsm_kfuncs_fail.c
> 
> 
> base-commit: d82ebfc685c91e7f5623a8be949da1ddb767420b

On Tue, Aug 18, 2026 at 11:47:55AM +0800, Xiujianfeng wrote:
> +cc Nicolas
> 
> On 8/15/2026 7:20 PM, 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.
> 
> Adding the bpf_security_locked_down() kfunc does not actually solve the
> TOCTOU issue you mentioned. Even after bpf_security_locked_down() is
> called, userspace can still change the lockdown state via /sys/kernel/
> security/lockdown.
> 
> I fail to see the necessity for a BPF program to know whether a specific
> operation is locked down.

I agree with Xiu.

> The test case provided in patch 2 does not
> clearly demonstrate a scenario where this is required. In my view, the
> verdict should happen exactly where security_locked_down() is currently
> invoked.
> 

> Furthermore, based on the current implementation of Lockdown, integrity
> is the prerequisite for confidentiality. It is designed to be coarse-
> grained and does not support per-operation lockdown. The fact that LSM
> BPF can already hook into locked_down seems to violate this foundational
> model, this is is analogous to the bitmap implementation [1], I’m
> considering whether we should restrict BPF from attaching to the
> locked_down hook. Nicolas, what are your thoughts on this?

I do not see any issue about LSM BPF being able to hook into
security_locked_down. If Lockdown is enabled in integrity mode, and a
BPF LSM hook authorizes let's say the LOCKDOWN_DEV_MEM reason, Lockdown
will deny it anyway.

IMHO, if one wants to disable the Lockdown LSM and implement it through
eBPF, if the implementation is bad, it is not our problem. Exactly as
for other LSM hooks.
> 
> [1]
> https://lore.kernel.org/all/20250728111517.134116-1-nik.borisov@suse.com/
> 
> > 
> > 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.
> > 
> > Justin

Nicolas

On Tue, Aug 18, 2026 at 11:47:55AM +0800, Xiujianfeng wrote:
> +cc Nicolas
> 
> On 8/15/2026 7:20 PM, 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.
> 
> Adding the bpf_security_locked_down() kfunc does not actually solve the
> TOCTOU issue you mentioned. Even after bpf_security_locked_down() is
> called, userspace can still change the lockdown state via /sys/kernel/
> security/lockdown.
>
This would put it at the same raciness level as any kernel caller of
security_locked_down.

More importantly, the sysfs file is not equivalent to calling the
hook. /sys/kernel/security/lockdown reflects only the lockdown LSM's
static level.

security_locked_down() is a generic LSM hook and other
implementers of locked_down: including BPF LSM programs attached to
that hook (which is already supported) can contribute per-reason,
dynamic verdicts that never appear in sysfs. The composite answer is
only obtainable by invoking the hook, which is what this kfunc exposes.

> I fail to see the necessity for a BPF program to know whether a specific
> operation is locked down. The test case provided in patch 2 does not
> clearly demonstrate a scenario where this is required. In my view, the
> verdict should happen exactly where security_locked_down() is currently
> invoked.
>
Elaborating a bit more on the use cases:

1. Being able to know if features LOCKDOWN_BPF_READ / LOCKDOWN_KPROBES is
   locked down without a userspace hop / polling an LSM-specific interface
   for error handling.

2. Use with the BPF LSM implmentations of security_locked_down, without
   Lockdown even in the picture.

3. A BPF LSM can restrict access to arbritrary sensitive resources based
   on the security_locked_down verdict.

> Furthermore, based on the current implementation of Lockdown, integrity
> is the prerequisite for confidentiality. It is designed to be coarse-
> grained and does not support per-operation lockdown. The fact that LSM
> BPF can already hook into locked_down seems to violate this foundational
> model, this is is analogous to the bitmap implementation [1], I’m
> considering whether we should restrict BPF from attaching to the
> locked_down hook. Nicolas, what are your thoughts on this?

You describe a Lockdown-specific model, why should other security models /
implementations of the same hook be made to have the same semantics?

The point of the LSM hooks are to be generic.

(I have use cases that do rely on that hook; though I'm embarrased to
speak on it and it is probably abuse: I use this hook to temporarily
disable hibernation in BPF)

Justin
> 
> [1]
> https://lore.kernel.org/all/20250728111517.134116-1-nik.borisov@suse.com/
> 
> > 
> > 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.
> > 
> > Justin
> > 
> > Justin Suess (2):
> >    lsm: add bpf_security_locked_down() kfunc
> >    selftests/bpf: Test bpf_security_locked_down kfunc
> > 
> >   security/Makefile                             |  1 +
> >   security/lsm_kfuncs.c                         | 84 +++++++++++++++++++
> >   .../selftests/bpf/prog_tests/lsm_kfuncs.c     | 28 +++++++
> >   .../testing/selftests/bpf/progs/lsm_kfuncs.c  | 34 ++++++++
> >   .../selftests/bpf/progs/lsm_kfuncs_fail.c     | 26 ++++++
> >   5 files changed, 173 insertions(+)
> >   create mode 100644 security/lsm_kfuncs.c
> >   create mode 100644 tools/testing/selftests/bpf/prog_tests/lsm_kfuncs.c
> >   create mode 100644 tools/testing/selftests/bpf/progs/lsm_kfuncs.c
> >   create mode 100644 tools/testing/selftests/bpf/progs/lsm_kfuncs_fail.c
> > 
> > 
> > base-commit: d82ebfc685c91e7f5623a8be949da1ddb767420b
> 

On 8/18/2026 12:46 PM, Justin Suess wrote:
> On Tue, Aug 18, 2026 at 11:47:55AM +0800, Xiujianfeng wrote:
>> +cc Nicolas
>>
>> On 8/15/2026 7:20 PM, 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.
>>
>> Adding the bpf_security_locked_down() kfunc does not actually solve the
>> TOCTOU issue you mentioned. Even after bpf_security_locked_down() is
>> called, userspace can still change the lockdown state via /sys/kernel/
>> security/lockdown.
>>
> This would put it at the same raciness level as any kernel caller of
> security_locked_down.
> 
> More importantly, the sysfs file is not equivalent to calling the
> hook. /sys/kernel/security/lockdown reflects only the lockdown LSM's
> static level.
> 
> security_locked_down() is a generic LSM hook and other
> implementers of locked_down: including BPF LSM programs attached to
> that hook (which is already supported) can contribute per-reason,
> dynamic verdicts that never appear in sysfs. The composite answer is
> only obtainable by invoking the hook, which is what this kfunc exposes.
> 
>> I fail to see the necessity for a BPF program to know whether a specific
>> operation is locked down. The test case provided in patch 2 does not
>> clearly demonstrate a scenario where this is required. In my view, the
>> verdict should happen exactly where security_locked_down() is currently
>> invoked.
>>
> Elaborating a bit more on the use cases:
> 
> 1. Being able to know if features LOCKDOWN_BPF_READ / LOCKDOWN_KPROBES is
>     locked down without a userspace hop / polling an LSM-specific interface
>     for error handling.
> 
> 2. Use with the BPF LSM implmentations of security_locked_down, without
>     Lockdown even in the picture.
> 
> 3. A BPF LSM can restrict access to arbritrary sensitive resources based
>     on the security_locked_down verdict.
> 

I stand by my view that LSM arbitration should happen right where the 
action is actually executed. Wrapping it inside BPF kfuncs introduces
dangerous nested invocations between LSM and BPF. While your patch
blocks the locked_down hook from calling bpf_security_locked_down, it is
a whack-a-mole workaround and does not alter the fact of nesting itself.

>> Furthermore, based on the current implementation of Lockdown, integrity
>> is the prerequisite for confidentiality. It is designed to be coarse-
>> grained and does not support per-operation lockdown. The fact that LSM
>> BPF can already hook into locked_down seems to violate this foundational
>> model, this is is analogous to the bitmap implementation [1], I’m
>> considering whether we should restrict BPF from attaching to the
>> locked_down hook. Nicolas, what are your thoughts on this?
> 
> You describe a Lockdown-specific model, why should other security models /
> implementations of the same hook be made to have the same semantics?
> 
> The point of the LSM hooks are to be generic.
> 
> (I have use cases that do rely on that hook; though I'm embarrased to
> speak on it and it is probably abuse: I use this hook to temporarily
> disable hibernation in BPF)
> 
> Justin
>>
>> [1]
>> https://lore.kernel.org/all/20250728111517.134116-1-nik.borisov@suse.com/
>>
>>>
>>> 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.
>>>
>>> Justin
>>>
>>> Justin Suess (2):
>>>     lsm: add bpf_security_locked_down() kfunc
>>>     selftests/bpf: Test bpf_security_locked_down kfunc
>>>
>>>    security/Makefile                             |  1 +
>>>    security/lsm_kfuncs.c                         | 84 +++++++++++++++++++
>>>    .../selftests/bpf/prog_tests/lsm_kfuncs.c     | 28 +++++++
>>>    .../testing/selftests/bpf/progs/lsm_kfuncs.c  | 34 ++++++++
>>>    .../selftests/bpf/progs/lsm_kfuncs_fail.c     | 26 ++++++
>>>    5 files changed, 173 insertions(+)
>>>    create mode 100644 security/lsm_kfuncs.c
>>>    create mode 100644 tools/testing/selftests/bpf/prog_tests/lsm_kfuncs.c
>>>    create mode 100644 tools/testing/selftests/bpf/progs/lsm_kfuncs.c
>>>    create mode 100644 tools/testing/selftests/bpf/progs/lsm_kfuncs_fail.c
>>>
>>>
>>> base-commit: d82ebfc685c91e7f5623a8be949da1ddb767420b
>>