mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: bot+bpf-ci@kernel.org
To: utilityemal77@gmail.com,ast@kernel.org,paul@paul-moore.com,xiujianfeng@huawei.com
Cc: linux-kernel@vger.kernel.org,linux-security-module@vger.kernel.org,bpf@vger.kernel.org,utilityemal77@gmail.com,ast@kernel.org,andrii@kernel.org,daniel@iogearbox.net,martin.lau@kernel.org,eddyz87@gmail.com,yonghong.song@linux.dev,clm@meta.com,ihor.solodrai@linux.dev
Subject: Re: [PATCH bpf-next 2/2] selftests/bpf: Test bpf_security_locked_down kfunc
Date: Sat, 15 Aug 2026 12:19:40 +0000 (UTC)	[thread overview]
Message-ID: <65c31dc7456f76e4b3012dd8dff3f7e23d136903d5cf997eb9be0662a979c1bc@mail.kernel.org> (raw)
In-Reply-To: <20260815112041.1248855-3-utilityemal77@gmail.com>

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

  reply	other threads:[~2026-08-15 12:19 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 message]
2026-08-18  3:47 ` [PATCH bpf-next 0/2] lsm: give BPF programs a way to query locked_down state Xiujianfeng
2026-08-18  4:46   ` Justin Suess
2026-08-18 10:54     ` Xiujianfeng
2026-08-18 11:08   ` Nicolas Bouchinet
2026-08-18  9:42 ` Kumar Kartikeya Dwivedi
2026-08-18 11:12   ` Justin Suess
2026-08-18 17:24   ` Justin Suess
2026-08-18 17:41   ` David Windsor
2026-08-18 19:48     ` Paul Moore
2026-08-18 20:16       ` David Windsor
2026-08-18 20:33         ` Paul Moore
2026-08-18 20:41           ` David Windsor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=65c31dc7456f76e4b3012dd8dff3f7e23d136903d5cf997eb9be0662a979c1bc@mail.kernel.org \
    --to=bot+bpf-ci@kernel.org \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=clm@meta.com \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=ihor.solodrai@linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=martin.lau@kernel.org \
    --cc=paul@paul-moore.com \
    --cc=utilityemal77@gmail.com \
    --cc=xiujianfeng@huawei.com \
    --cc=yonghong.song@linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®