Linux Security Modules development
 help / color / mirror / Atom feed
* [PATCH bpf-next 0/2] lsm: give BPF programs a way to query locked_down state
@ 2026-08-15 11:20 Justin Suess
  2026-08-15 11:20 ` [PATCH bpf-next 1/2] lsm: add bpf_security_locked_down() kfunc Justin Suess
  2026-08-15 11:20 ` [PATCH bpf-next 2/2] selftests/bpf: Test bpf_security_locked_down kfunc Justin Suess
  0 siblings, 2 replies; 5+ messages in thread
From: Justin Suess @ 2026-08-15 11:20 UTC (permalink / raw)
  To: Alexei Starovoitov, Paul Moore, Xiu Jianfeng
  Cc: linux-kernel, linux-security-module, bpf, Justin Suess

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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [PATCH bpf-next 1/2] lsm: add bpf_security_locked_down() kfunc
  2026-08-15 11:20 [PATCH bpf-next 0/2] lsm: give BPF programs a way to query locked_down state Justin Suess
@ 2026-08-15 11:20 ` Justin Suess
  2026-08-15 12:19   ` bot+bpf-ci
  2026-08-15 11:20 ` [PATCH bpf-next 2/2] selftests/bpf: Test bpf_security_locked_down kfunc Justin Suess
  1 sibling, 1 reply; 5+ messages in thread
From: Justin Suess @ 2026-08-15 11:20 UTC (permalink / raw)
  To: Alexei Starovoitov, Paul Moore, Xiu Jianfeng
  Cc: linux-kernel, linux-security-module, bpf, Justin Suess

Add a new kfunc bpf_security_locked_down, which calls
security_locked_down and returns the result.

Create a new file security/lsm_kfuncs.c for LSM framework kfuncs.

Reject reasons outside (LOCKDOWN_NONE, LOCKDOWN_CONFIDENTIALITY_MAX)
with -EINVAL before dispatching the hook. Limit the kfunc to
BPF_PROG_TYPE_LSM and BPF_PROG_TYPE_SYSCALL programs, and refuse it
to programs attached to the locked_down hook itself, which would
recurse into the dispatch.

Signed-off-by: Justin Suess <utilityemal77@gmail.com>
---
 security/Makefile     |  1 +
 security/lsm_kfuncs.c | 84 +++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 85 insertions(+)
 create mode 100644 security/lsm_kfuncs.c

diff --git a/security/Makefile b/security/Makefile
index 4601230ba442..dee8ff218548 100644
--- a/security/Makefile
+++ b/security/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_MMU)			+= min_addr.o
 
 # Object file lists
 obj-$(CONFIG_SECURITY)			+= security.o lsm_notifier.o lsm_init.o
+obj-$(CONFIG_BPF_SYSCALL)		+= lsm_kfuncs.o
 obj-$(CONFIG_SECURITYFS)		+= inode.o
 obj-$(CONFIG_SECURITY_SELINUX)		+= selinux/
 obj-$(CONFIG_SECURITY_SMACK)		+= smack/
diff --git a/security/lsm_kfuncs.c b/security/lsm_kfuncs.c
new file mode 100644
index 000000000000..a324e7d978ca
--- /dev/null
+++ b/security/lsm_kfuncs.c
@@ -0,0 +1,84 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * kfuncs exposing LSM interfaces to BPF programs.
+ *
+ * Copyright (C) 2026 Justin Suess
+ */
+#include <linux/bpf.h>
+#include <linux/btf.h>
+#include <linux/btf_ids.h>
+#include <linux/init.h>
+#include <linux/security.h>
+
+__bpf_kfunc_start_defs();
+
+/**
+ * bpf_security_locked_down - Call the security_locked_down() LSM hook
+ * @what: lockdown reason to query
+ *
+ * Return: 0 if @what is not locked down, -EPERM if it is, or -EINVAL if
+ * @what is outside (LOCKDOWN_NONE, LOCKDOWN_CONFIDENTIALITY_MAX).
+ */
+__bpf_kfunc int bpf_security_locked_down(enum lockdown_reason what)
+{
+	if (what <= LOCKDOWN_NONE || what >= LOCKDOWN_CONFIDENTIALITY_MAX)
+		return -EINVAL;
+	return security_locked_down(what);
+}
+
+__bpf_kfunc_end_defs();
+
+BTF_KFUNCS_START(lsm_kfunc_ids)
+BTF_ID_FLAGS(func, bpf_security_locked_down)
+BTF_KFUNCS_END(lsm_kfunc_ids)
+
+#ifdef CONFIG_BPF_LSM
+BTF_ID_LIST_SINGLE(lsm_locked_down_hook_id, func, bpf_lsm_locked_down)
+#endif
+
+static int lsm_kfunc_filter(const struct bpf_prog *prog, u32 kfunc_id)
+{
+	/* Filters run for every kfunc resolved through the hook. */
+	if (!btf_id_set8_contains(&lsm_kfunc_ids, kfunc_id))
+		return 0;
+
+	/*
+	 * Raw prog->type: keep out the rest of the shared tracing kfunc
+	 * set (incl. perf/NMI) and extension programs.
+	 */
+	switch (prog->type) {
+	case BPF_PROG_TYPE_SYSCALL:
+		return 0;
+#ifdef CONFIG_BPF_LSM
+	case BPF_PROG_TYPE_LSM:
+		/*
+		 * A locked_down program calling this kfunc would recurse.
+		 * Match on attach_btf_id: attach_func_name is not yet set
+		 * when the filter runs from check_cfg.
+		 */
+		if (prog->aux->attach_btf_id == lsm_locked_down_hook_id[0])
+			return -EACCES;
+		return 0;
+#endif
+	default:
+		return -EACCES;
+	}
+}
+
+static const struct btf_kfunc_id_set lsm_kfunc_set = {
+	.owner  = THIS_MODULE,
+	.set    = &lsm_kfunc_ids,
+	.filter = lsm_kfunc_filter,
+};
+
+static int __init lsm_kfuncs_init(void)
+{
+	int err;
+
+	err = register_btf_kfunc_id_set(BPF_PROG_TYPE_LSM, &lsm_kfunc_set);
+	err = err ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_SYSCALL, &lsm_kfunc_set);
+	if (err)
+		pr_warn("lsm_kfuncs: kfunc registration failed: %d\n", err);
+	return err;
+}
+late_initcall(lsm_kfuncs_init);
-- 
2.54.0


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* [PATCH bpf-next 2/2] selftests/bpf: Test bpf_security_locked_down kfunc
  2026-08-15 11:20 [PATCH bpf-next 0/2] lsm: give BPF programs a way to query locked_down state Justin Suess
  2026-08-15 11:20 ` [PATCH bpf-next 1/2] lsm: add bpf_security_locked_down() kfunc Justin Suess
@ 2026-08-15 11:20 ` Justin Suess
  2026-08-15 12:19   ` bot+bpf-ci
  1 sibling, 1 reply; 5+ messages in thread
From: Justin Suess @ 2026-08-15 11:20 UTC (permalink / raw)
  To: Alexei Starovoitov, Paul Moore, Xiu Jianfeng
  Cc: linux-kernel, linux-security-module, bpf, Justin Suess

Test the bpf_security_locked_down() kfunc. An LSM program attached to
the locked_down hook denies LOCKDOWN_HIBERNATION, so a syscall program
querying the kfunc observes both verdicts deterministically without
touching real lockdown state: 0 for LOCKDOWN_KEXEC and -EPERM for
LOCKDOWN_HIBERNATION. Out-of-range reasons must return -EINVAL.

Programs in denied calling contexts (a tracing program, and an LSM
program attached to the locked_down hook itself) must be rejected at
load time by the kfunc filter.

The selftest config guarantees the verdicts are stable: the bpf LSM is
in CONFIG_LSM and the lockdown LSM is not, so the kernel cannot already
be locked down.

Signed-off-by: Justin Suess <utilityemal77@gmail.com>
---
 .../selftests/bpf/prog_tests/lsm_kfuncs.c     | 28 +++++++++++++++
 .../testing/selftests/bpf/progs/lsm_kfuncs.c  | 34 +++++++++++++++++++
 .../selftests/bpf/progs/lsm_kfuncs_fail.c     | 26 ++++++++++++++
 3 files changed, 88 insertions(+)
 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

diff --git a/tools/testing/selftests/bpf/prog_tests/lsm_kfuncs.c b/tools/testing/selftests/bpf/prog_tests/lsm_kfuncs.c
new file mode 100644
index 000000000000..c836851d8397
--- /dev/null
+++ b/tools/testing/selftests/bpf/prog_tests/lsm_kfuncs.c
@@ -0,0 +1,28 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <test_progs.h>
+#include "lsm_kfuncs.skel.h"
+#include "lsm_kfuncs_fail.skel.h"
+
+void test_lsm_kfuncs(void)
+{
+	LIBBPF_OPTS(bpf_test_run_opts, opts);
+	struct lsm_kfuncs *skel;
+
+	RUN_TESTS(lsm_kfuncs_fail);
+
+	skel = lsm_kfuncs__open_and_load();
+	if (!ASSERT_OK_PTR(skel, "open_and_load"))
+		return;
+	if (!ASSERT_OK(lsm_kfuncs__attach(skel), "attach"))
+		goto out;
+
+	if (!ASSERT_OK(bpf_prog_test_run_opts(bpf_program__fd(skel->progs.query),
+					      &opts), "test_run"))
+		goto out;
+	ASSERT_EQ(skel->data->ret_clear, 0, "not locked down");
+	ASSERT_EQ(skel->data->ret_denied, -EPERM, "locked down");
+	ASSERT_EQ(skel->data->ret_invalid_low, -EINVAL, "LOCKDOWN_NONE invalid");
+	ASSERT_EQ(skel->data->ret_invalid_high, -EINVAL, "CONFIDENTIALITY_MAX invalid");
+out:
+	lsm_kfuncs__destroy(skel);
+}
diff --git a/tools/testing/selftests/bpf/progs/lsm_kfuncs.c b/tools/testing/selftests/bpf/progs/lsm_kfuncs.c
new file mode 100644
index 000000000000..2637b9bc9025
--- /dev/null
+++ b/tools/testing/selftests/bpf/progs/lsm_kfuncs.c
@@ -0,0 +1,34 @@
+// SPDX-License-Identifier: GPL-2.0
+#include "vmlinux.h"
+#include <errno.h>
+#include <bpf/bpf_helpers.h>
+#include <bpf/bpf_tracing.h>
+
+char _license[] SEC("license") = "GPL";
+
+extern int bpf_security_locked_down(enum lockdown_reason what) __ksym;
+
+/* Reason nothing in the test environment genuinely queries or locks. */
+#define DENY_REASON LOCKDOWN_HIBERNATION
+#define ALLOW_REASON LOCKDOWN_KEXEC
+
+int ret_clear = 1;
+int ret_denied = 1;
+int ret_invalid_low = 1;
+int ret_invalid_high = 1;
+
+SEC("lsm/locked_down")
+int BPF_PROG(lockdown_hook, enum lockdown_reason what)
+{
+	return what == DENY_REASON ? -EPERM : 0;
+}
+
+SEC("syscall")
+int query(void *ctx)
+{
+	ret_clear = bpf_security_locked_down(ALLOW_REASON);
+	ret_denied = bpf_security_locked_down(DENY_REASON);
+	ret_invalid_low = bpf_security_locked_down(LOCKDOWN_NONE);
+	ret_invalid_high = bpf_security_locked_down(LOCKDOWN_CONFIDENTIALITY_MAX);
+	return 0;
+}
diff --git a/tools/testing/selftests/bpf/progs/lsm_kfuncs_fail.c b/tools/testing/selftests/bpf/progs/lsm_kfuncs_fail.c
new file mode 100644
index 000000000000..b9861d9c4f16
--- /dev/null
+++ b/tools/testing/selftests/bpf/progs/lsm_kfuncs_fail.c
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: GPL-2.0
+#include "vmlinux.h"
+#include <bpf/bpf_helpers.h>
+#include <bpf/bpf_tracing.h>
+#include "bpf_misc.h"
+
+char _license[] SEC("license") = "GPL";
+
+extern int bpf_security_locked_down(enum lockdown_reason what) __ksym;
+
+/* Tracing programs must be rejected by the kfunc filter. */
+SEC("fentry/bpf_fentry_test1")
+__failure __msg("calling kernel function bpf_security_locked_down is not allowed")
+int BPF_PROG(tracing_caller, int a)
+{
+	bpf_security_locked_down(LOCKDOWN_KEXEC);
+	return 0;
+}
+
+/* As must locked_down programs, which would recurse into the dispatch. */
+SEC("lsm/locked_down")
+__failure __msg("calling kernel function bpf_security_locked_down is not allowed")
+int BPF_PROG(recursive_caller, enum lockdown_reason what)
+{
+	return bpf_security_locked_down(what);
+}
-- 
2.54.0


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH bpf-next 2/2] selftests/bpf: Test bpf_security_locked_down kfunc
  2026-08-15 11:20 ` [PATCH bpf-next 2/2] selftests/bpf: Test bpf_security_locked_down kfunc Justin Suess
@ 2026-08-15 12:19   ` bot+bpf-ci
  0 siblings, 0 replies; 5+ messages in thread
From: bot+bpf-ci @ 2026-08-15 12:19 UTC (permalink / raw)
  To: utilityemal77, ast, paul, xiujianfeng
  Cc: linux-kernel, linux-security-module, bpf, utilityemal77, ast,
	andrii, daniel, martin.lau, eddyz87, yonghong.song, clm,
	ihor.solodrai

[-- Attachment #1: Type: text/plain, Size: 4573 bytes --]

> The selftest config guarantees the verdicts are stable: the bpf LSM is
> in CONFIG_LSM and the lockdown LSM is not, so the kernel cannot already
> be locked down.

Does the selftest config actually guarantee this? Looking at
tools/testing/selftests/bpf/config, it sets only CONFIG_BPF_LSM=y,
CONFIG_SECURITY=y and CONFIG_SECURITYFS=y. There is no CONFIG_LSM line at
all in that file.

The only CONFIG_LSM in the bpf selftest configs is
tools/testing/selftests/bpf/config.x86_64, which has
CONFIG_LSM="selinux,bpf,integrity". On other arch configs (aarch64,
s390x, riscv64, ppc64el), CONFIG_LSM falls back to the security/Kconfig
default, which does list "lockdown".

What actually prevents the lockdown LSM from being active is that
CONFIG_SECURITY_LOCKDOWN_LSM defaults to n, so the lockdown LSM registers
no hook. This is a weaker guarantee than the changelog states, and only
holds when test_progs is run against the shipped selftest config.

> diff --git a/tools/testing/selftests/bpf/prog_tests/lsm_kfuncs.c b/tools/testing/selftests/bpf/prog_tests/lsm_kfuncs.c
> new file mode 100644
> index 000000000000..c836851d8397
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/prog_tests/lsm_kfuncs.c
> @@ -0,0 +1,28 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include <test_progs.h>
> +#include "lsm_kfuncs.skel.h"
> +#include "lsm_kfuncs_fail.skel.h"
> +
> +void test_lsm_kfuncs(void)
> +{
> +	LIBBPF_OPTS(bpf_test_run_opts, opts);
> +	struct lsm_kfuncs *skel;
> +
> +	RUN_TESTS(lsm_kfuncs_fail);
> +
> +	skel = lsm_kfuncs__open_and_load();
> +	if (!ASSERT_OK_PTR(skel, "open_and_load"))
> +		return;
> +	if (!ASSERT_OK(lsm_kfuncs__attach(skel), "attach"))
> +		goto out;
> +
> +	if (!ASSERT_OK(bpf_prog_test_run_opts(bpf_program__fd(skel->progs.query),
> +					      &opts), "test_run"))
> +		goto out;
> +	ASSERT_EQ(skel->data->ret_clear, 0, "not locked down");

Can this assertion produce false failures on a kernel that is already
locked down? If CONFIG_SECURITY_LOCKDOWN_LSM=y with lockdown active
(lockdown=integrity/confidentiality, or Secure Boot with
CONFIG_LOCK_DOWN_KERNEL_FORCE_*), security_locked_down() walks every
registered locked_down hook, not just the test's BPF program.

security/lockdown/lockdown.c:
    LSM_HOOK_INIT(locked_down, lockdown_is_locked_down)

would return -EPERM for LOCKDOWN_KEXEC (an integrity-level reason), so
ret_clear becomes -EPERM and the test reports a hard FAIL rather than a
skip.

> +	ASSERT_EQ(skel->data->ret_denied, -EPERM, "locked down");
> +	ASSERT_EQ(skel->data->ret_invalid_low, -EINVAL, "LOCKDOWN_NONE invalid");
> +	ASSERT_EQ(skel->data->ret_invalid_high, -EINVAL, "CONFIDENTIALITY_MAX invalid");
> +out:
> +	lsm_kfuncs__destroy(skel);
> +}

[ ... ]

> diff --git a/tools/testing/selftests/bpf/progs/lsm_kfuncs.c b/tools/testing/selftests/bpf/progs/lsm_kfuncs.c
> new file mode 100644
> index 000000000000..2637b9bc9025
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/progs/lsm_kfuncs.c
> @@ -0,0 +1,34 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include "vmlinux.h"
> +#include <errno.h>
> +#include <bpf/bpf_helpers.h>
> +#include <bpf/bpf_tracing.h>
> +
> +char _license[] SEC("license") = "GPL";
> +
> +extern int bpf_security_locked_down(enum lockdown_reason what) __ksym;
> +
> +/* Reason nothing in the test environment genuinely queries or locks. */
> +#define DENY_REASON LOCKDOWN_HIBERNATION
> +#define ALLOW_REASON LOCKDOWN_KEXEC
> +
> +int ret_clear = 1;
> +int ret_denied = 1;
> +int ret_invalid_low = 1;
> +int ret_invalid_high = 1;
> +
> +SEC("lsm/locked_down")
> +int BPF_PROG(lockdown_hook, enum lockdown_reason what)
> +{
> +	return what == DENY_REASON ? -EPERM : 0;
> +}
> +
> +SEC("syscall")
> +int query(void *ctx)
> +{
> +	ret_clear = bpf_security_locked_down(ALLOW_REASON);

Would it make sense to have the test tolerate or skip when the running
kernel is already locked down? The current approach asserts on global host
state the test does not control. Consider checking if ret_clear != 0 and
skipping with a message, so the test does not produce false regression
signals on distro kernels with lockdown active.

> +	ret_denied = bpf_security_locked_down(DENY_REASON);
> +	ret_invalid_low = bpf_security_locked_down(LOCKDOWN_NONE);
> +	ret_invalid_high = bpf_security_locked_down(LOCKDOWN_CONFIDENTIALITY_MAX);
> +	return 0;
> +}

[ ... ]


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/31882515336

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH bpf-next 1/2] lsm: add bpf_security_locked_down() kfunc
  2026-08-15 11:20 ` [PATCH bpf-next 1/2] lsm: add bpf_security_locked_down() kfunc Justin Suess
@ 2026-08-15 12:19   ` bot+bpf-ci
  0 siblings, 0 replies; 5+ messages in thread
From: bot+bpf-ci @ 2026-08-15 12:19 UTC (permalink / raw)
  To: utilityemal77, ast, paul, xiujianfeng
  Cc: linux-kernel, linux-security-module, bpf, utilityemal77, ast,
	andrii, daniel, martin.lau, eddyz87, yonghong.song, clm,
	ihor.solodrai

[-- Attachment #1: Type: text/plain, Size: 992 bytes --]

> lsm: add bpf_security_locked_down() kfunc
>
> Add a new kfunc bpf_security_locked_down, which calls
> security_locked_down and returns the result.
>
> Create a new file security/lsm_kfuncs.c for LSM framework kfuncs.
>
> Reject reasons outside (LOCKDOWN_NONE, LOCKDOWN_CONFIDENTIALITY_MAX)
> with -EINVAL before dispatching the hook. Limit the kfunc to
> BPF_PROG_TYPE_LSM and BPF_PROG_TYPE_SYSCALL programs, and refuse it
> to programs attached to the locked_down hook itself, which would
> recurse into the dispatch.
>
> Signed-off-by: Justin Suess <utilityemal77@gmail.com>

This isn't a bug, but could the changelog lead with the use case that
motivates exposing security_locked_down() to BPF programs, instead of
restating what each hunk does?


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/31882515336

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2026-08-15 12:19 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-08-15 11:20 [PATCH bpf-next 0/2] lsm: give BPF programs a way to query locked_down state Justin Suess
2026-08-15 11:20 ` [PATCH bpf-next 1/2] lsm: add bpf_security_locked_down() kfunc Justin Suess
2026-08-15 12:19   ` bot+bpf-ci
2026-08-15 11:20 ` [PATCH bpf-next 2/2] selftests/bpf: Test bpf_security_locked_down kfunc Justin Suess
2026-08-15 12:19   ` bot+bpf-ci

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox