* Re: [RFC PATCH v2 31/34] ima,evm: move initcalls to the LSM framework
From: Nicolas Bouchinet @ 2025-07-28 9:46 UTC (permalink / raw)
To: Paul Moore
Cc: linux-security-module, linux-integrity, selinux, John Johansen,
Mimi Zohar, Roberto Sassu, Fan Wu, Mickaël Salaün,
Günther Noack, Kees Cook, Micah Morton, Casey Schaufler,
Tetsuo Handa, Xiu Jianfeng
In-Reply-To: <20250721232142.77224-67-paul@paul-moore.com>
Hi Paul,
With `CONFIG_INTEGRITY=y` but not `CONFIG_IMA=y` or `CONFIG_EVM=y` it
does not compile :
```
ld: vmlinux.o: in function `integrity_late_init':
security/integrity/initcalls.c:32:(.init.text+0x47f85): undefined reference to `init_ima'
ld: security/integrity/initcalls.c:36:(.init.text+0x47f96): undefined reference to `init_evm'
make[2]: *** [scripts/Makefile.vmlinux:91: vmlinux.unstripped] Error 1
make[1]: *** [Makefile:1236: vmlinux] Error 2
make: *** [Makefile:248: __sub-make] Error 2
```
> security/integrity/Makefile | 2 +-
> security/integrity/evm/evm_main.c | 6 ++---
> security/integrity/iint.c | 4 +--
> security/integrity/ima/ima_main.c | 6 ++---
> security/integrity/initcalls.c | 41 +++++++++++++++++++++++++++++++
> security/integrity/initcalls.h | 13 ++++++++++
> 6 files changed, 63 insertions(+), 9 deletions(-)
> create mode 100644 security/integrity/initcalls.c
> create mode 100644 security/integrity/initcalls.h
>
> diff --git a/security/integrity/Makefile b/security/integrity/Makefile
> index 92b63039c654..6ea330ea88b1 100644
> --- a/security/integrity/Makefile
> +++ b/security/integrity/Makefile
> @@ -5,7 +5,7 @@
>
> obj-$(CONFIG_INTEGRITY) += integrity.o
>
> -integrity-y := iint.o
> +integrity-y := iint.o initcalls.o
> integrity-$(CONFIG_INTEGRITY_AUDIT) += integrity_audit.o
> integrity-$(CONFIG_INTEGRITY_SIGNATURE) += digsig.o
> integrity-$(CONFIG_INTEGRITY_ASYMMETRIC_KEYS) += digsig_asymmetric.o
---
> diff --git a/security/integrity/initcalls.h b/security/integrity/initcalls.h
> new file mode 100644
> index 000000000000..5511c62f8166
> --- /dev/null
> +++ b/security/integrity/initcalls.h
> @@ -0,0 +1,13 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +
> +#ifndef PLATFORM_CERTS_INITCALLS_H
> +#define PLATFORM_CERTS_INITCALLS_H
> +
> +int integrity_fs_init(void);
> +
> +int init_ima(void);
> +int init_evm(void);
> +
> +int integrity_late_init(void);
> +
> +#endif
> --
> 2.50.1
>
Nicolas
^ permalink raw reply
* Re: [RFC PATCH v2 31/34] ima,evm: move initcalls to the LSM framework
From: Roberto Sassu @ 2025-07-28 10:43 UTC (permalink / raw)
To: Nicolas Bouchinet, Paul Moore
Cc: linux-security-module, linux-integrity, selinux, John Johansen,
Mimi Zohar, Roberto Sassu, Fan Wu, Mickaël Salaün,
Günther Noack, Kees Cook, Micah Morton, Casey Schaufler,
Tetsuo Handa, Xiu Jianfeng
In-Reply-To: <st4eimc4lovdeqrtxfhwjpgcblyufzahec2hmtrxvkpp4woejw@iqeuzubt7afe>
On Mon, 2025-07-28 at 11:46 +0200, Nicolas Bouchinet wrote:
> Hi Paul,
>
> With `CONFIG_INTEGRITY=y` but not `CONFIG_IMA=y` or `CONFIG_EVM=y` it
> does not compile :
Hi Nicolas
thanks, I was about to answer too:
Same type of change as for Smack (I didn't check the other LSMs):
diff --git a/security/integrity/initcalls.h
b/security/integrity/initcalls.h
index 5511c62f8166..a0e27fab67db 100644
--- a/security/integrity/initcalls.h
+++ b/security/integrity/initcalls.h
@@ -5,8 +5,23 @@
int integrity_fs_init(void);
+#ifdef CONFIG_IMA
int init_ima(void);
+#else
+static inline int init_ima(void)
+{
+ return 0;
+}
+#endif
+
+#ifdef CONFIG_EVM
int init_evm(void);
+#else
+static inline int init_evm(void)
+{
+ return 0;
+}
+#endif
int integrity_late_init(void);
Plus:
diff --git a/security/integrity/initcalls.c
b/security/integrity/initcalls.c
index 92ec9f0aa2a7..6afa411068f2 100644
--- a/security/integrity/initcalls.c
+++ b/security/integrity/initcalls.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * Platform certificate / keyring initcalls
+ * IMA/EVM initcalls
*
*/
Thanks
Roberto
> ```
> ld: vmlinux.o: in function `integrity_late_init':
> security/integrity/initcalls.c:32:(.init.text+0x47f85): undefined reference to `init_ima'
> ld: security/integrity/initcalls.c:36:(.init.text+0x47f96): undefined reference to `init_evm'
> make[2]: *** [scripts/Makefile.vmlinux:91: vmlinux.unstripped] Error 1
> make[1]: *** [Makefile:1236: vmlinux] Error 2
> make: *** [Makefile:248: __sub-make] Error 2
> ```
>
> > security/integrity/Makefile | 2 +-
> > security/integrity/evm/evm_main.c | 6 ++---
> > security/integrity/iint.c | 4 +--
> > security/integrity/ima/ima_main.c | 6 ++---
> > security/integrity/initcalls.c | 41 +++++++++++++++++++++++++++++++
> > security/integrity/initcalls.h | 13 ++++++++++
> > 6 files changed, 63 insertions(+), 9 deletions(-)
> > create mode 100644 security/integrity/initcalls.c
> > create mode 100644 security/integrity/initcalls.h
> >
> > diff --git a/security/integrity/Makefile b/security/integrity/Makefile
> > index 92b63039c654..6ea330ea88b1 100644
> > --- a/security/integrity/Makefile
> > +++ b/security/integrity/Makefile
> > @@ -5,7 +5,7 @@
> >
> > obj-$(CONFIG_INTEGRITY) += integrity.o
> >
> > -integrity-y := iint.o
> > +integrity-y := iint.o initcalls.o
> > integrity-$(CONFIG_INTEGRITY_AUDIT) += integrity_audit.o
> > integrity-$(CONFIG_INTEGRITY_SIGNATURE) += digsig.o
> > integrity-$(CONFIG_INTEGRITY_ASYMMETRIC_KEYS) += digsig_asymmetric.o
>
> ---
>
> > diff --git a/security/integrity/initcalls.h b/security/integrity/initcalls.h
> > new file mode 100644
> > index 000000000000..5511c62f8166
> > --- /dev/null
> > +++ b/security/integrity/initcalls.h
> > @@ -0,0 +1,13 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +
> > +#ifndef PLATFORM_CERTS_INITCALLS_H
> > +#define PLATFORM_CERTS_INITCALLS_H
> > +
> > +int integrity_fs_init(void);
> > +
> > +int init_ima(void);
> > +int init_evm(void);
> > +
> > +int integrity_late_init(void);
> > +
> > +#endif
> > --
> > 2.50.1
> >
>
> Nicolas
^ permalink raw reply related
* [PATCH v2 0/3] Allow individual features to be locked down
From: Nikolay Borisov @ 2025-07-28 11:15 UTC (permalink / raw)
To: linux-security-module
Cc: linux-kernel, paul, serge, jmorris, dan.j.williams,
Nikolay Borisov
This simple change allows usecases where someone might want to lock only specific
feature at a finer granularity than integrity/confidentiality levels allows.
The first likely user of this is the CoCo subsystem where certain features will be
disabled.
Changes since v1:
* Added Patch 3 to incoroporate Serge's hardening suggestion
Nikolay Borisov (3):
lockdown: Switch implementation to using bitmap
lockdown/kunit: Introduce kunit tests
lockdown: Use snprintf in lockdown_read
security/lockdown/Kconfig | 5 +++
security/lockdown/Makefile | 1 +
security/lockdown/lockdown.c | 36 +++++++++++++++------
security/lockdown/lockdown_test.c | 54 +++++++++++++++++++++++++++++++
4 files changed, 86 insertions(+), 10 deletions(-)
create mode 100644 security/lockdown/lockdown_test.c
--
2.34.1
^ permalink raw reply
* [PATCH v2 1/3] lockdown: Switch implementation to using bitmap
From: Nikolay Borisov @ 2025-07-28 11:15 UTC (permalink / raw)
To: linux-security-module
Cc: linux-kernel, paul, serge, jmorris, dan.j.williams,
Nikolay Borisov
In-Reply-To: <20250728111517.134116-1-nik.borisov@suse.com>
Tracking the lockdown at the depth granularity rather than at the
individual is somewhat inflexible as it provides an "all or nothing"
approach. Instead there are use cases where it will be useful to be
able to lockdown individual features - TDX for example wants to disable
access to just /dev/mem.
To accommodate this use case switch the internal implementation to using
a bitmap so that individual lockdown features can be turned on. At the
same time retain the existing semantic where
INTEGRITY_MAX/CONFIDENTIALITY_MAX are treated as wildcards meaning "lock
everything below me".
Signed-off-by: Nikolay Borisov <nik.borisov@suse.com>
---
security/lockdown/lockdown.c | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/security/lockdown/lockdown.c b/security/lockdown/lockdown.c
index cf83afa1d879..5014d18c423f 100644
--- a/security/lockdown/lockdown.c
+++ b/security/lockdown/lockdown.c
@@ -10,12 +10,13 @@
* 2 of the Licence, or (at your option) any later version.
*/
+#include <linux/bitmap.h>
#include <linux/security.h>
#include <linux/export.h>
#include <linux/lsm_hooks.h>
#include <uapi/linux/lsm.h>
-static enum lockdown_reason kernel_locked_down;
+static DECLARE_BITMAP(kernel_locked_down, LOCKDOWN_CONFIDENTIALITY_MAX);
static const enum lockdown_reason lockdown_levels[] = {LOCKDOWN_NONE,
LOCKDOWN_INTEGRITY_MAX,
@@ -26,10 +27,15 @@ static const enum lockdown_reason lockdown_levels[] = {LOCKDOWN_NONE,
*/
static int lock_kernel_down(const char *where, enum lockdown_reason level)
{
- if (kernel_locked_down >= level)
- return -EPERM;
- kernel_locked_down = level;
+ if (level > LOCKDOWN_CONFIDENTIALITY_MAX)
+ return -EINVAL;
+
+ if (level == LOCKDOWN_INTEGRITY_MAX || level == LOCKDOWN_CONFIDENTIALITY_MAX)
+ bitmap_set(kernel_locked_down, 1, level);
+ else
+ bitmap_set(kernel_locked_down, level, 1);
+
pr_notice("Kernel is locked down from %s; see man kernel_lockdown.7\n",
where);
return 0;
@@ -62,13 +68,12 @@ static int lockdown_is_locked_down(enum lockdown_reason what)
"Invalid lockdown reason"))
return -EPERM;
- if (kernel_locked_down >= what) {
+ if (test_bit(what, kernel_locked_down)) {
if (lockdown_reasons[what])
pr_notice_ratelimited("Lockdown: %s: %s is restricted; see man kernel_lockdown.7\n",
current->comm, lockdown_reasons[what]);
return -EPERM;
}
-
return 0;
}
@@ -105,7 +110,7 @@ static ssize_t lockdown_read(struct file *filp, char __user *buf, size_t count,
if (lockdown_reasons[level]) {
const char *label = lockdown_reasons[level];
- if (kernel_locked_down == level)
+ if (test_bit(level, kernel_locked_down))
offset += sprintf(temp+offset, "[%s] ", label);
else
offset += sprintf(temp+offset, "%s ", label);
--
2.34.1
^ permalink raw reply related
* [PATCH v2 2/3] lockdown/kunit: Introduce kunit tests
From: Nikolay Borisov @ 2025-07-28 11:15 UTC (permalink / raw)
To: linux-security-module
Cc: linux-kernel, paul, serge, jmorris, dan.j.williams,
Nikolay Borisov
In-Reply-To: <20250728111517.134116-1-nik.borisov@suse.com>
Add a bunch of tests to ensure lockdown's conversion to bitmap hasn't
regressed it.
Signed-off-by: Nikolay Borisov <nik.borisov@suse.com>
---
security/lockdown/Kconfig | 5 +++
security/lockdown/Makefile | 1 +
security/lockdown/lockdown.c | 5 ++-
security/lockdown/lockdown_test.c | 54 +++++++++++++++++++++++++++++++
4 files changed, 64 insertions(+), 1 deletion(-)
create mode 100644 security/lockdown/lockdown_test.c
diff --git a/security/lockdown/Kconfig b/security/lockdown/Kconfig
index e84ddf484010..5fb750da1f8c 100644
--- a/security/lockdown/Kconfig
+++ b/security/lockdown/Kconfig
@@ -6,6 +6,11 @@ config SECURITY_LOCKDOWN_LSM
Build support for an LSM that enforces a coarse kernel lockdown
behaviour.
+config SECURITY_LOCKDOWN_LSM_TEST
+ tristate "Test lockdown functionality" if !KUNIT_ALL_TESTS
+ depends on SECURITY_LOCKDOWN_LSM && KUNIT
+ default KUNIT_ALL_TESTS
+
config SECURITY_LOCKDOWN_LSM_EARLY
bool "Enable lockdown LSM early in init"
depends on SECURITY_LOCKDOWN_LSM
diff --git a/security/lockdown/Makefile b/security/lockdown/Makefile
index e3634b9017e7..f35d90e39f1c 100644
--- a/security/lockdown/Makefile
+++ b/security/lockdown/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_SECURITY_LOCKDOWN_LSM) += lockdown.o
+obj-$(CONFIG_SECURITY_LOCKDOWN_LSM_TEST) += lockdown_test.o
diff --git a/security/lockdown/lockdown.c b/security/lockdown/lockdown.c
index 5014d18c423f..412184121279 100644
--- a/security/lockdown/lockdown.c
+++ b/security/lockdown/lockdown.c
@@ -25,7 +25,10 @@ static const enum lockdown_reason lockdown_levels[] = {LOCKDOWN_NONE,
/*
* Put the kernel into lock-down mode.
*/
-static int lock_kernel_down(const char *where, enum lockdown_reason level)
+#if !IS_ENABLED(CONFIG_KUNIT)
+static
+#endif
+int lock_kernel_down(const char *where, enum lockdown_reason level)
{
if (level > LOCKDOWN_CONFIDENTIALITY_MAX)
diff --git a/security/lockdown/lockdown_test.c b/security/lockdown/lockdown_test.c
new file mode 100644
index 000000000000..3a3c6db5b470
--- /dev/null
+++ b/security/lockdown/lockdown_test.c
@@ -0,0 +1,54 @@
+#include <linux/security.h>
+#include <kunit/test.h>
+
+int lock_kernel_down(const char *where, enum lockdown_reason level);
+
+static void lockdown_test_invalid_level(struct kunit *test)
+{
+ KUNIT_EXPECT_EQ(test, -EINVAL, lock_kernel_down("TEST", LOCKDOWN_CONFIDENTIALITY_MAX+1));
+}
+
+static void lockdown_test_depth_locking(struct kunit *test)
+{
+ KUNIT_EXPECT_EQ(test, 0, lock_kernel_down("TEST", LOCKDOWN_INTEGRITY_MAX));
+ for (int i = 1; i < LOCKDOWN_INTEGRITY_MAX; i++)
+ KUNIT_EXPECT_EQ_MSG(test, -EPERM, security_locked_down(i), "at i=%d", i);
+
+ KUNIT_EXPECT_EQ(test, -EPERM, security_locked_down(LOCKDOWN_INTEGRITY_MAX));
+}
+
+static void lockdown_test_individual_level(struct kunit *test)
+{
+ KUNIT_EXPECT_EQ(test, 0, lock_kernel_down("TEST", LOCKDOWN_PERF));
+ KUNIT_EXPECT_EQ(test, -EPERM, security_locked_down(LOCKDOWN_PERF));
+ /* Ensure adjacent levels are untouched */
+ KUNIT_EXPECT_EQ(test, 0, security_locked_down(LOCKDOWN_TRACEFS));
+ KUNIT_EXPECT_EQ(test, 0, security_locked_down(LOCKDOWN_DBG_READ_KERNEL));
+}
+
+static void lockdown_test_no_downgrade(struct kunit *test)
+{
+ KUNIT_EXPECT_EQ(test, 0, lock_kernel_down("TEST", LOCKDOWN_CONFIDENTIALITY_MAX));
+ KUNIT_EXPECT_EQ(test, 0, lock_kernel_down("TEST", LOCKDOWN_INTEGRITY_MAX));
+ /*
+ * Ensure having locked down to a lower leve after a higher level
+ * lockdown nothing is lost
+ */
+ KUNIT_EXPECT_EQ(test, -EPERM, security_locked_down(LOCKDOWN_TRACEFS));
+}
+
+static struct kunit_case lockdown_tests[] = {
+ KUNIT_CASE(lockdown_test_invalid_level),
+ KUNIT_CASE(lockdown_test_depth_locking),
+ KUNIT_CASE(lockdown_test_individual_level),
+ KUNIT_CASE(lockdown_test_no_downgrade),
+ {}
+};
+
+static struct kunit_suite lockdown_test_suite = {
+ .name = "lockdown test",
+ .test_cases = lockdown_tests,
+};
+kunit_test_suite(lockdown_test_suite);
+
+MODULE_LICENSE("GPL");
--
2.34.1
^ permalink raw reply related
* [PATCH v2 3/3] lockdown: Use snprintf in lockdown_read
From: Nikolay Borisov @ 2025-07-28 11:15 UTC (permalink / raw)
To: linux-security-module
Cc: linux-kernel, paul, serge, jmorris, dan.j.williams,
Nikolay Borisov
In-Reply-To: <20250728111517.134116-1-nik.borisov@suse.com>
Since individual features are now locked down separately ensure that if
the printing code is change to list them a buffer overrun won't be
introduced. As per Serge's recommendation switch from using sprintf to
using snprintf and return EINVAL in case longer than 80 char string hasi
to be printed.
Signed-off-by: Nikolay Borisov <nik.borisov@suse.com>
---
security/lockdown/lockdown.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/security/lockdown/lockdown.c b/security/lockdown/lockdown.c
index 412184121279..ed1dde41d7d3 100644
--- a/security/lockdown/lockdown.c
+++ b/security/lockdown/lockdown.c
@@ -112,11 +112,19 @@ static ssize_t lockdown_read(struct file *filp, char __user *buf, size_t count,
if (lockdown_reasons[level]) {
const char *label = lockdown_reasons[level];
+ int ret = 0;
+ int write_len = 80-offset;
+
if (test_bit(level, kernel_locked_down))
- offset += sprintf(temp+offset, "[%s] ", label);
+ ret = snprintf(temp+offset, write_len, "[%s] ", label);
else
- offset += sprintf(temp+offset, "%s ", label);
+ ret = snprintf(temp+offset, write_len, "%s ", label);
+
+ if (ret < 0 || ret >= write_len)
+ return -ENOMEM;
+
+ offset += ret;
}
}
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 3/3] lockdown: Use snprintf in lockdown_read
From: Serge E. Hallyn @ 2025-07-28 12:39 UTC (permalink / raw)
To: Nikolay Borisov
Cc: linux-security-module, linux-kernel, paul, serge, jmorris,
dan.j.williams
In-Reply-To: <20250728111517.134116-4-nik.borisov@suse.com>
On Mon, Jul 28, 2025 at 02:15:17PM +0300, Nikolay Borisov wrote:
> Since individual features are now locked down separately ensure that if
> the printing code is change to list them a buffer overrun won't be
> introduced. As per Serge's recommendation switch from using sprintf to
> using snprintf and return EINVAL in case longer than 80 char string hasi
> to be printed.
>
> Signed-off-by: Nikolay Borisov <nik.borisov@suse.com>
Thanks, 2 comments below
> ---
> security/lockdown/lockdown.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/security/lockdown/lockdown.c b/security/lockdown/lockdown.c
> index 412184121279..ed1dde41d7d3 100644
> --- a/security/lockdown/lockdown.c
> +++ b/security/lockdown/lockdown.c
> @@ -112,11 +112,19 @@ static ssize_t lockdown_read(struct file *filp, char __user *buf, size_t count,
>
> if (lockdown_reasons[level]) {
> const char *label = lockdown_reasons[level];
> + int ret = 0;
> + int write_len = 80-offset;
80 should really be a #define (and used to declare the length of temp as
well).
> +
>
> if (test_bit(level, kernel_locked_down))
> - offset += sprintf(temp+offset, "[%s] ", label);
> + ret = snprintf(temp+offset, write_len, "[%s] ", label);
> else
> - offset += sprintf(temp+offset, "%s ", label);
> + ret = snprintf(temp+offset, write_len, "%s ", label);
> +
> + if (ret < 0 || ret >= write_len)
> + return -ENOMEM;
is ENOMEM right here, or should it be something like EINVAL or E2BIG?
> +
> + offset += ret;
> }
> }
>
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v2 1/3] lockdown: Switch implementation to using bitmap
From: Serge E. Hallyn @ 2025-07-28 12:47 UTC (permalink / raw)
To: Nikolay Borisov
Cc: linux-security-module, linux-kernel, paul, serge, jmorris,
dan.j.williams
In-Reply-To: <20250728111517.134116-2-nik.borisov@suse.com>
On Mon, Jul 28, 2025 at 02:15:15PM +0300, Nikolay Borisov wrote:
> Tracking the lockdown at the depth granularity rather than at the
> individual is somewhat inflexible as it provides an "all or nothing"
> approach. Instead there are use cases where it will be useful to be
> able to lockdown individual features - TDX for example wants to disable
> access to just /dev/mem.
>
> To accommodate this use case switch the internal implementation to using
> a bitmap so that individual lockdown features can be turned on. At the
> same time retain the existing semantic where
> INTEGRITY_MAX/CONFIDENTIALITY_MAX are treated as wildcards meaning "lock
> everything below me".
>
> Signed-off-by: Nikolay Borisov <nik.borisov@suse.com>
> ---
> security/lockdown/lockdown.c | 19 ++++++++++++-------
> 1 file changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/security/lockdown/lockdown.c b/security/lockdown/lockdown.c
> index cf83afa1d879..5014d18c423f 100644
> --- a/security/lockdown/lockdown.c
> +++ b/security/lockdown/lockdown.c
> @@ -10,12 +10,13 @@
> * 2 of the Licence, or (at your option) any later version.
> */
>
> +#include <linux/bitmap.h>
> #include <linux/security.h>
> #include <linux/export.h>
> #include <linux/lsm_hooks.h>
> #include <uapi/linux/lsm.h>
>
> -static enum lockdown_reason kernel_locked_down;
> +static DECLARE_BITMAP(kernel_locked_down, LOCKDOWN_CONFIDENTIALITY_MAX);
>
> static const enum lockdown_reason lockdown_levels[] = {LOCKDOWN_NONE,
> LOCKDOWN_INTEGRITY_MAX,
> @@ -26,10 +27,15 @@ static const enum lockdown_reason lockdown_levels[] = {LOCKDOWN_NONE,
> */
> static int lock_kernel_down(const char *where, enum lockdown_reason level)
> {
> - if (kernel_locked_down >= level)
> - return -EPERM;
>
> - kernel_locked_down = level;
> + if (level > LOCKDOWN_CONFIDENTIALITY_MAX)
> + return -EINVAL;
> +
> + if (level == LOCKDOWN_INTEGRITY_MAX || level == LOCKDOWN_CONFIDENTIALITY_MAX)
For the reviewer (including me), it would be good to have a comment here or at
top of fn to ease our minds that this is really what's meant: So if we lock
down with reason LOCKDOWN_INTEGRITY_MAX, we want to set all bits up to
LOCKDOWN_INTEGRITY_MAX, which is not the whole array, and if setting
LOCKDOWN_CONFIDENTIALITY_MAX, then we want to set *all* bits, right?
So LOCKDOWN_CONFIDENTIALITY_MAX is a supserset of LOCKDOWN_INTEGRITY_MAX?
And for anything else, set the single bit.
> + bitmap_set(kernel_locked_down, 1, level);
> + else
> + bitmap_set(kernel_locked_down, level, 1);
> +
> pr_notice("Kernel is locked down from %s; see man kernel_lockdown.7\n",
> where);
> return 0;
> @@ -62,13 +68,12 @@ static int lockdown_is_locked_down(enum lockdown_reason what)
> "Invalid lockdown reason"))
> return -EPERM;
>
> - if (kernel_locked_down >= what) {
> + if (test_bit(what, kernel_locked_down)) {
> if (lockdown_reasons[what])
> pr_notice_ratelimited("Lockdown: %s: %s is restricted; see man kernel_lockdown.7\n",
> current->comm, lockdown_reasons[what]);
> return -EPERM;
> }
> -
> return 0;
> }
>
> @@ -105,7 +110,7 @@ static ssize_t lockdown_read(struct file *filp, char __user *buf, size_t count,
> if (lockdown_reasons[level]) {
> const char *label = lockdown_reasons[level];
>
> - if (kernel_locked_down == level)
> + if (test_bit(level, kernel_locked_down))
> offset += sprintf(temp+offset, "[%s] ", label);
> else
> offset += sprintf(temp+offset, "%s ", label);
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v2 2/3] lockdown/kunit: Introduce kunit tests
From: Serge E. Hallyn @ 2025-07-28 12:49 UTC (permalink / raw)
To: Nikolay Borisov
Cc: linux-security-module, linux-kernel, paul, serge, jmorris,
dan.j.williams
In-Reply-To: <20250728111517.134116-3-nik.borisov@suse.com>
On Mon, Jul 28, 2025 at 02:15:16PM +0300, Nikolay Borisov wrote:
> Add a bunch of tests to ensure lockdown's conversion to bitmap hasn't
> regressed it.
>
> Signed-off-by: Nikolay Borisov <nik.borisov@suse.com>
Reviewed-by: Serge Hallyn <serge@hallyn.com>
(And I see this answers my question to patch 1, but still a comment
there would be nice :)
thanks,
-serge
> ---
> security/lockdown/Kconfig | 5 +++
> security/lockdown/Makefile | 1 +
> security/lockdown/lockdown.c | 5 ++-
> security/lockdown/lockdown_test.c | 54 +++++++++++++++++++++++++++++++
> 4 files changed, 64 insertions(+), 1 deletion(-)
> create mode 100644 security/lockdown/lockdown_test.c
>
> diff --git a/security/lockdown/Kconfig b/security/lockdown/Kconfig
> index e84ddf484010..5fb750da1f8c 100644
> --- a/security/lockdown/Kconfig
> +++ b/security/lockdown/Kconfig
> @@ -6,6 +6,11 @@ config SECURITY_LOCKDOWN_LSM
> Build support for an LSM that enforces a coarse kernel lockdown
> behaviour.
>
> +config SECURITY_LOCKDOWN_LSM_TEST
> + tristate "Test lockdown functionality" if !KUNIT_ALL_TESTS
> + depends on SECURITY_LOCKDOWN_LSM && KUNIT
> + default KUNIT_ALL_TESTS
> +
> config SECURITY_LOCKDOWN_LSM_EARLY
> bool "Enable lockdown LSM early in init"
> depends on SECURITY_LOCKDOWN_LSM
> diff --git a/security/lockdown/Makefile b/security/lockdown/Makefile
> index e3634b9017e7..f35d90e39f1c 100644
> --- a/security/lockdown/Makefile
> +++ b/security/lockdown/Makefile
> @@ -1 +1,2 @@
> obj-$(CONFIG_SECURITY_LOCKDOWN_LSM) += lockdown.o
> +obj-$(CONFIG_SECURITY_LOCKDOWN_LSM_TEST) += lockdown_test.o
> diff --git a/security/lockdown/lockdown.c b/security/lockdown/lockdown.c
> index 5014d18c423f..412184121279 100644
> --- a/security/lockdown/lockdown.c
> +++ b/security/lockdown/lockdown.c
> @@ -25,7 +25,10 @@ static const enum lockdown_reason lockdown_levels[] = {LOCKDOWN_NONE,
> /*
> * Put the kernel into lock-down mode.
> */
> -static int lock_kernel_down(const char *where, enum lockdown_reason level)
> +#if !IS_ENABLED(CONFIG_KUNIT)
> +static
> +#endif
> +int lock_kernel_down(const char *where, enum lockdown_reason level)
> {
>
> if (level > LOCKDOWN_CONFIDENTIALITY_MAX)
> diff --git a/security/lockdown/lockdown_test.c b/security/lockdown/lockdown_test.c
> new file mode 100644
> index 000000000000..3a3c6db5b470
> --- /dev/null
> +++ b/security/lockdown/lockdown_test.c
> @@ -0,0 +1,54 @@
> +#include <linux/security.h>
> +#include <kunit/test.h>
> +
> +int lock_kernel_down(const char *where, enum lockdown_reason level);
> +
> +static void lockdown_test_invalid_level(struct kunit *test)
> +{
> + KUNIT_EXPECT_EQ(test, -EINVAL, lock_kernel_down("TEST", LOCKDOWN_CONFIDENTIALITY_MAX+1));
> +}
> +
> +static void lockdown_test_depth_locking(struct kunit *test)
> +{
> + KUNIT_EXPECT_EQ(test, 0, lock_kernel_down("TEST", LOCKDOWN_INTEGRITY_MAX));
> + for (int i = 1; i < LOCKDOWN_INTEGRITY_MAX; i++)
> + KUNIT_EXPECT_EQ_MSG(test, -EPERM, security_locked_down(i), "at i=%d", i);
> +
> + KUNIT_EXPECT_EQ(test, -EPERM, security_locked_down(LOCKDOWN_INTEGRITY_MAX));
> +}
> +
> +static void lockdown_test_individual_level(struct kunit *test)
> +{
> + KUNIT_EXPECT_EQ(test, 0, lock_kernel_down("TEST", LOCKDOWN_PERF));
> + KUNIT_EXPECT_EQ(test, -EPERM, security_locked_down(LOCKDOWN_PERF));
> + /* Ensure adjacent levels are untouched */
> + KUNIT_EXPECT_EQ(test, 0, security_locked_down(LOCKDOWN_TRACEFS));
> + KUNIT_EXPECT_EQ(test, 0, security_locked_down(LOCKDOWN_DBG_READ_KERNEL));
> +}
> +
> +static void lockdown_test_no_downgrade(struct kunit *test)
> +{
> + KUNIT_EXPECT_EQ(test, 0, lock_kernel_down("TEST", LOCKDOWN_CONFIDENTIALITY_MAX));
> + KUNIT_EXPECT_EQ(test, 0, lock_kernel_down("TEST", LOCKDOWN_INTEGRITY_MAX));
> + /*
> + * Ensure having locked down to a lower leve after a higher level
> + * lockdown nothing is lost
> + */
> + KUNIT_EXPECT_EQ(test, -EPERM, security_locked_down(LOCKDOWN_TRACEFS));
> +}
> +
> +static struct kunit_case lockdown_tests[] = {
> + KUNIT_CASE(lockdown_test_invalid_level),
> + KUNIT_CASE(lockdown_test_depth_locking),
> + KUNIT_CASE(lockdown_test_individual_level),
> + KUNIT_CASE(lockdown_test_no_downgrade),
> + {}
> +};
> +
> +static struct kunit_suite lockdown_test_suite = {
> + .name = "lockdown test",
> + .test_cases = lockdown_tests,
> +};
> +kunit_test_suite(lockdown_test_suite);
> +
> +MODULE_LICENSE("GPL");
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v2 1/3] lockdown: Switch implementation to using bitmap
From: Serge E. Hallyn @ 2025-07-28 13:21 UTC (permalink / raw)
To: Nikolay Borisov
Cc: linux-security-module, linux-kernel, paul, serge, jmorris,
dan.j.williams
In-Reply-To: <20250728111517.134116-2-nik.borisov@suse.com>
On Mon, Jul 28, 2025 at 02:15:15PM +0300, Nikolay Borisov wrote:
> Tracking the lockdown at the depth granularity rather than at the
> individual is somewhat inflexible as it provides an "all or nothing"
> approach. Instead there are use cases where it will be useful to be
> able to lockdown individual features - TDX for example wants to disable
> access to just /dev/mem.
>
> To accommodate this use case switch the internal implementation to using
> a bitmap so that individual lockdown features can be turned on. At the
> same time retain the existing semantic where
> INTEGRITY_MAX/CONFIDENTIALITY_MAX are treated as wildcards meaning "lock
> everything below me".
>
> Signed-off-by: Nikolay Borisov <nik.borisov@suse.com>
Would still like to see the comment, but, with or without it,
looks good, thank you.
Reviewed-by: Serge Hallyn <serge@hallyn.com>
> ---
> security/lockdown/lockdown.c | 19 ++++++++++++-------
> 1 file changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/security/lockdown/lockdown.c b/security/lockdown/lockdown.c
> index cf83afa1d879..5014d18c423f 100644
> --- a/security/lockdown/lockdown.c
> +++ b/security/lockdown/lockdown.c
> @@ -10,12 +10,13 @@
> * 2 of the Licence, or (at your option) any later version.
> */
>
> +#include <linux/bitmap.h>
> #include <linux/security.h>
> #include <linux/export.h>
> #include <linux/lsm_hooks.h>
> #include <uapi/linux/lsm.h>
>
> -static enum lockdown_reason kernel_locked_down;
> +static DECLARE_BITMAP(kernel_locked_down, LOCKDOWN_CONFIDENTIALITY_MAX);
>
> static const enum lockdown_reason lockdown_levels[] = {LOCKDOWN_NONE,
> LOCKDOWN_INTEGRITY_MAX,
> @@ -26,10 +27,15 @@ static const enum lockdown_reason lockdown_levels[] = {LOCKDOWN_NONE,
> */
> static int lock_kernel_down(const char *where, enum lockdown_reason level)
> {
> - if (kernel_locked_down >= level)
> - return -EPERM;
>
> - kernel_locked_down = level;
> + if (level > LOCKDOWN_CONFIDENTIALITY_MAX)
> + return -EINVAL;
> +
> + if (level == LOCKDOWN_INTEGRITY_MAX || level == LOCKDOWN_CONFIDENTIALITY_MAX)
> + bitmap_set(kernel_locked_down, 1, level);
> + else
> + bitmap_set(kernel_locked_down, level, 1);
> +
> pr_notice("Kernel is locked down from %s; see man kernel_lockdown.7\n",
> where);
> return 0;
> @@ -62,13 +68,12 @@ static int lockdown_is_locked_down(enum lockdown_reason what)
> "Invalid lockdown reason"))
> return -EPERM;
>
> - if (kernel_locked_down >= what) {
> + if (test_bit(what, kernel_locked_down)) {
> if (lockdown_reasons[what])
> pr_notice_ratelimited("Lockdown: %s: %s is restricted; see man kernel_lockdown.7\n",
> current->comm, lockdown_reasons[what]);
> return -EPERM;
> }
> -
> return 0;
> }
>
> @@ -105,7 +110,7 @@ static ssize_t lockdown_read(struct file *filp, char __user *buf, size_t count,
> if (lockdown_reasons[level]) {
> const char *label = lockdown_reasons[level];
>
> - if (kernel_locked_down == level)
> + if (test_bit(level, kernel_locked_down))
> offset += sprintf(temp+offset, "[%s] ", label);
> else
> offset += sprintf(temp+offset, "%s ", label);
> --
> 2.34.1
>
^ permalink raw reply
* Re: [RFC PATCH v2 30/34] lockdown: move initcalls to the LSM framework
From: Paul Moore @ 2025-07-28 21:49 UTC (permalink / raw)
To: xiujianfeng
Cc: linux-security-module, linux-integrity, selinux, John Johansen,
Mimi Zohar, Roberto Sassu, Fan Wu, Mickaël Salaün,
Günther Noack, Kees Cook, Micah Morton, Casey Schaufler,
Tetsuo Handa, Nicolas Bouchinet
In-Reply-To: <68025cd0-e55a-066e-954e-a398feedc34b@huawei.com>
On Sat, Jul 26, 2025 at 5:38 AM xiujianfeng <xiujianfeng@huawei.com> wrote:
> On 2025/7/26 0:51, Paul Moore wrote:
> > On Fri, Jul 25, 2025 at 4:12 AM Xiu Jianfeng
> > <xiujianfeng@huaweicloud.com> wrote:
> >> On 2025/7/22 7:21, Paul Moore wrote:
> >>> Reviewed-by: Kees Cook <kees@kernel.org>
> >>> Signed-off-by: Paul Moore <paul@paul-moore.com>
> >>
> >> Reviewed-by: Xiu Jianfeng <xiujianfeng@huawei.com>
> >
> > Thank you for reviewing this patch. As you are a Lockdown maintainer,
> > can I change your reviewed-by into an acked-by tag?
>
> Yes, absolutely! Thanks for checking!
Done, thanks!
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH v2 2/3] lockdown/kunit: Introduce kunit tests
From: kernel test robot @ 2025-07-28 22:04 UTC (permalink / raw)
To: Nikolay Borisov, linux-security-module
Cc: llvm, oe-kbuild-all, linux-kernel, paul, serge, jmorris,
dan.j.williams, Nikolay Borisov
In-Reply-To: <20250728111517.134116-3-nik.borisov@suse.com>
Hi Nikolay,
kernel test robot noticed the following build warnings:
[auto build test WARNING on linus/master]
[also build test WARNING on v6.16 next-20250728]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Nikolay-Borisov/lockdown-Switch-implementation-to-using-bitmap/20250728-191807
base: linus/master
patch link: https://lore.kernel.org/r/20250728111517.134116-3-nik.borisov%40suse.com
patch subject: [PATCH v2 2/3] lockdown/kunit: Introduce kunit tests
config: arm-randconfig-004-20250729 (https://download.01.org/0day-ci/archive/20250729/202507290540.9IANrMED-lkp@intel.com/config)
compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project 1b4db78d2eaa070b3f364a2d2b2b826a5439b892)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250729/202507290540.9IANrMED-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202507290540.9IANrMED-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> security/lockdown/lockdown.c:31:5: warning: no previous prototype for function 'lock_kernel_down' [-Wmissing-prototypes]
31 | int lock_kernel_down(const char *where, enum lockdown_reason level)
| ^
security/lockdown/lockdown.c:31:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
31 | int lock_kernel_down(const char *where, enum lockdown_reason level)
| ^
| static
1 warning generated.
vim +/lock_kernel_down +31 security/lockdown/lockdown.c
20
21 static const enum lockdown_reason lockdown_levels[] = {LOCKDOWN_NONE,
22 LOCKDOWN_INTEGRITY_MAX,
23 LOCKDOWN_CONFIDENTIALITY_MAX};
24
25 /*
26 * Put the kernel into lock-down mode.
27 */
28 #if !IS_ENABLED(CONFIG_KUNIT)
29 static
30 #endif
> 31 int lock_kernel_down(const char *where, enum lockdown_reason level)
32 {
33
34 if (level > LOCKDOWN_CONFIDENTIALITY_MAX)
35 return -EINVAL;
36
37 if (level == LOCKDOWN_INTEGRITY_MAX || level == LOCKDOWN_CONFIDENTIALITY_MAX)
38 bitmap_set(kernel_locked_down, 1, level);
39 else
40 bitmap_set(kernel_locked_down, level, 1);
41
42 pr_notice("Kernel is locked down from %s; see man kernel_lockdown.7\n",
43 where);
44 return 0;
45 }
46
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [RFC PATCH v2 26/34] smack: move initcalls to the LSM framework
From: Paul Moore @ 2025-07-28 22:34 UTC (permalink / raw)
To: Roberto Sassu, Casey Schaufler
Cc: linux-security-module, linux-integrity, selinux, John Johansen,
Mimi Zohar, Roberto Sassu, Fan Wu, Mickaël Salaün,
Günther Noack, Kees Cook, Micah Morton, Tetsuo Handa,
Nicolas Bouchinet, Xiu Jianfeng
In-Reply-To: <5ff016adea8969e4a97387d4ed88a172bdc4b3de.camel@huaweicloud.com>
On Mon, Jul 28, 2025 at 5:46 AM Roberto Sassu
<roberto.sassu@huaweicloud.com> wrote:
> On Mon, 2025-07-21 at 19:21 -0400, Paul Moore wrote:
> > As the LSM framework only supports one LSM initcall callback for each
> > initcall type, the init_smk_fs() and smack_nf_ip_init() functions were
> > wrapped with a new function, smack_initcall() that is registered with
> > the LSM framework.
> >
> > Signed-off-by: Paul Moore <paul@paul-moore.com>
> > ---
> > security/smack/smack.h | 7 +++++++
> > security/smack/smack_lsm.c | 9 +++++++++
> > security/smack/smack_netfilter.c | 4 +---
> > security/smack/smackfs.c | 4 +---
> > 4 files changed, 18 insertions(+), 6 deletions(-)
> >
> > diff --git a/security/smack/smack.h b/security/smack/smack.h
> > index bf6a6ed3946c..885a2f2929fd 100644
> > --- a/security/smack/smack.h
> > +++ b/security/smack/smack.h
> > @@ -275,6 +275,13 @@ struct smk_audit_info {
> > #endif
> > };
> >
> > +/*
> > + * Initialization
> > + */
> > +int init_smk_fs(void);
> > +int smack_nf_ip_init(void);
>
> I made the following changes (due to not having
> CONFIG_SECURITY_SMACK_NETFILTER) ...
Nice catch, thanks Roberto!
I made a slight change to use the defined(SMACK_NETFILTER) macro as
done elsewhere in the Smack code, but otherwise it looks good to me.
Casey, are you okay with this?
diff --git a/security/smack/smack.h b/security/smack/smack.h
index 885a2f2929fd..3662d61bb32e 100644
--- a/security/smack/smack.h
+++ b/security/smack/smack.h
@@ -278,8 +278,15 @@ struct smk_audit_info {
/*
* Initialization
*/
-int init_smk_fs(void);
+#if defined(CONFIG_SECURITY_SMACK_NETFILTER)
int smack_nf_ip_init(void);
+#else
+static inline int smack_nf_ip_init(void);
+{
+ return 0;
+}
+#endif
+int init_smk_fs(void);
int smack_initcall(void);
--
paul-moore.com
^ permalink raw reply related
* Re: [RFC PATCH v2 31/34] ima,evm: move initcalls to the LSM framework
From: Paul Moore @ 2025-07-28 23:17 UTC (permalink / raw)
To: Roberto Sassu
Cc: Nicolas Bouchinet, linux-security-module, linux-integrity,
selinux, John Johansen, Mimi Zohar, Roberto Sassu, Fan Wu,
Mickaël Salaün, Günther Noack, Kees Cook,
Micah Morton, Casey Schaufler, Tetsuo Handa, Xiu Jianfeng
In-Reply-To: <6c5ebaa88d1ee15046e9ea0bc61d9a843b850200.camel@huaweicloud.com>
On Mon, Jul 28, 2025 at 6:44 AM Roberto Sassu
<roberto.sassu@huaweicloud.com> wrote:
> On Mon, 2025-07-28 at 11:46 +0200, Nicolas Bouchinet wrote:
> > Hi Paul,
> >
> > With `CONFIG_INTEGRITY=y` but not `CONFIG_IMA=y` or `CONFIG_EVM=y` it
> > does not compile :
>
> Hi Nicolas
>
> thanks, I was about to answer too ...
Fixed, thanks everyone.
--
paul-moore.com
^ permalink raw reply
* Re: [RFC PATCH v2 26/34] smack: move initcalls to the LSM framework
From: Casey Schaufler @ 2025-07-28 23:56 UTC (permalink / raw)
To: Paul Moore, Roberto Sassu
Cc: linux-security-module, linux-integrity, selinux, John Johansen,
Mimi Zohar, Roberto Sassu, Fan Wu, Mickaël Salaün,
Günther Noack, Kees Cook, Micah Morton, Tetsuo Handa,
Nicolas Bouchinet, Xiu Jianfeng, Casey Schaufler
In-Reply-To: <CAHC9VhTh1=Qh2_4YKsXyC8dT6BFyh3nVbhfexLFsAWh7wiUCjg@mail.gmail.com>
On 7/28/2025 3:34 PM, Paul Moore wrote:
> On Mon, Jul 28, 2025 at 5:46 AM Roberto Sassu
> <roberto.sassu@huaweicloud.com> wrote:
>> On Mon, 2025-07-21 at 19:21 -0400, Paul Moore wrote:
>>> As the LSM framework only supports one LSM initcall callback for each
>>> initcall type, the init_smk_fs() and smack_nf_ip_init() functions were
>>> wrapped with a new function, smack_initcall() that is registered with
>>> the LSM framework.
>>>
>>> Signed-off-by: Paul Moore <paul@paul-moore.com>
>>> ---
>>> security/smack/smack.h | 7 +++++++
>>> security/smack/smack_lsm.c | 9 +++++++++
>>> security/smack/smack_netfilter.c | 4 +---
>>> security/smack/smackfs.c | 4 +---
>>> 4 files changed, 18 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/security/smack/smack.h b/security/smack/smack.h
>>> index bf6a6ed3946c..885a2f2929fd 100644
>>> --- a/security/smack/smack.h
>>> +++ b/security/smack/smack.h
>>> @@ -275,6 +275,13 @@ struct smk_audit_info {
>>> #endif
>>> };
>>>
>>> +/*
>>> + * Initialization
>>> + */
>>> +int init_smk_fs(void);
>>> +int smack_nf_ip_init(void);
>> I made the following changes (due to not having
>> CONFIG_SECURITY_SMACK_NETFILTER) ...
> Nice catch, thanks Roberto!
>
> I made a slight change to use the defined(SMACK_NETFILTER) macro as
> done elsewhere in the Smack code, but otherwise it looks good to me.
> Casey, are you okay with this?
Sure.
>
> diff --git a/security/smack/smack.h b/security/smack/smack.h
> index 885a2f2929fd..3662d61bb32e 100644
> --- a/security/smack/smack.h
> +++ b/security/smack/smack.h
> @@ -278,8 +278,15 @@ struct smk_audit_info {
> /*
> * Initialization
> */
> -int init_smk_fs(void);
> +#if defined(CONFIG_SECURITY_SMACK_NETFILTER)
> int smack_nf_ip_init(void);
> +#else
> +static inline int smack_nf_ip_init(void);
> +{
> + return 0;
> +}
> +#endif
> +int init_smk_fs(void);
> int smack_initcall(void);
>
^ permalink raw reply
* [GIT PULL] IPE update for 6.17
From: Fan Wu @ 2025-07-29 2:15 UTC (permalink / raw)
To: torvalds, linux-security-module, Linux Kernel Mailing List,
Eric Biggers
Hi Linus,
Please merge this PR for the IPE update for 6.17.
This PR contains a single commit from Eric Biggers. It simplifies IPE
policy audit with SHA-256 library API.
This commit has been tested for several weeks in linux-next without any issues.
Thanks,
Fan
--
The following changes since commit 038d61fd642278bab63ee8ef722c50d10ab01e8f:
Linux 6.16 (2025-07-27 14:26:38 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/wufan/ipe.git
tags/ipe-pr-20250728
for you to fetch changes up to b90bb6dbf1d60d70969f8f8f2f30033f49711594:
ipe: use SHA-256 library API instead of crypto_shash API (2025-07-28
18:54:18 -0700)
----------------------------------------------------------------
ipe/stable-6.17 PR 20250728
----------------------------------------------------------------
Eric Biggers (1):
ipe: use SHA-256 library API instead of crypto_shash API
security/ipe/Kconfig | 1 +
security/ipe/audit.c | 33 +++++----------------------------
2 files changed, 6 insertions(+), 28 deletions(-)
^ permalink raw reply
* Re: [GIT PULL] Landlock update for v6.17-rc1
From: pr-tracker-bot @ 2025-07-29 2:24 UTC (permalink / raw)
To: Mickaël Salaün
Cc: Linus Torvalds, Mickaël Salaün, Brahmajit Das,
Günther Noack, Song Liu, Tingmao Wang, linux-kernel,
linux-security-module
In-Reply-To: <20250725095511.446960-1-mic@digikod.net>
The pull request you sent on Fri, 25 Jul 2025 11:55:11 +0200:
> https://git.kernel.org/pub/scm/linux/kernel/git/mic/linux.git tags/landlock-6.17-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/ae388edd4a8f0226f3ef7b102c34f78220756c3d
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [GIT PULL] lsm/lsm-pr-20250725
From: pr-tracker-bot @ 2025-07-29 2:24 UTC (permalink / raw)
To: Paul Moore; +Cc: Linus Torvalds, linux-security-module, linux-kernel
In-Reply-To: <a981f40c12a45fe974beb197fa7b86dc@paul-moore.com>
The pull request you sent on Fri, 25 Jul 2025 16:49:02 -0400:
> https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm.git tags/lsm-pr-20250725
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/30b9dcae9815ae7e752fe3aa00aa283fadf16c6a
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [GIT PULL] selinux/selinux-pr-20250725
From: pr-tracker-bot @ 2025-07-29 2:24 UTC (permalink / raw)
To: Paul Moore; +Cc: Linus Torvalds, selinux, linux-security-module, linux-kernel
In-Reply-To: <6e344a8bd7d60522825222628e949a14@paul-moore.com>
The pull request you sent on Fri, 25 Jul 2025 16:49:27 -0400:
> https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git tags/selinux-pr-20250725
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/dffb641bea1d0c5a4017771aafb39513701095be
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH v2 04/13] libbpf: Support exclusive map creation
From: Alexei Starovoitov @ 2025-07-29 2:25 UTC (permalink / raw)
To: KP Singh
Cc: bpf, LSM List, Blaise Boscaccy, Paul Moore, K. Y. Srinivasan,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko
In-Reply-To: <20250721211958.1881379-5-kpsingh@kernel.org>
On Mon, Jul 21, 2025 at 2:20 PM KP Singh <kpsingh@kernel.org> wrote:
>
>
> +/**
> + * @brief **bpf_map__get_exclusive_program()** returns the exclusive program
> + * that is registered with the map (if any).
> + * @param map BPF map to which the exclusive program is registered.
> + * @return the registered exclusive program.
> + */
> +LIBBPF_API struct bpf_program *bpf_map__get_exclusive_program(struct bpf_map *map);
I couldn't find patches where it's used.
Do we actually need it?
^ permalink raw reply
* Re: [PATCH v2 12/13] selftests/bpf: Enable signature verification for all lskel tests
From: Alexei Starovoitov @ 2025-07-29 2:27 UTC (permalink / raw)
To: KP Singh
Cc: bpf, LSM List, Blaise Boscaccy, Paul Moore, K. Y. Srinivasan,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko
In-Reply-To: <20250721211958.1881379-13-kpsingh@kernel.org>
On Mon, Jul 21, 2025 at 2:20 PM KP Singh <kpsingh@kernel.org> wrote:
>
>
> +LSKEL_SIGN := -S -k $(PRIVATE_KEY) -i $(VERIFICATION_CERT)
> TRUNNER_OUTPUT := $(OUTPUT)$(if $2,/)$2
> TRUNNER_BINARY := $1$(if $2,-)$2
> TRUNNER_TEST_OBJS := $$(patsubst %.c,$$(TRUNNER_OUTPUT)/%.test.o, \
> @@ -601,7 +602,7 @@ $(TRUNNER_BPF_LSKELS): %.lskel.h: %.bpf.o $(BPFTOOL) | $(TRUNNER_OUTPUT)
> $(Q)$$(BPFTOOL) gen object $$(<:.o=.llinked2.o) $$(<:.o=.llinked1.o)
> $(Q)$$(BPFTOOL) gen object $$(<:.o=.llinked3.o) $$(<:.o=.llinked2.o)
> $(Q)diff $$(<:.o=.llinked2.o) $$(<:.o=.llinked3.o)
> - $(Q)$$(BPFTOOL) gen skeleton -L $$(<:.o=.llinked3.o) name $$(notdir $$(<:.bpf.o=_lskel)) > $$@
> + $(Q)$$(BPFTOOL) gen skeleton $(LSKEL_SIGN) $$(<:.o=.llinked3.o) name $$(notdir $$(<:.bpf.o=_lskel)) > $$@
> $(Q)rm -f $$(<:.o=.llinked1.o) $$(<:.o=.llinked2.o) $$(<:.o=.llinked3.o)
Does it mean that it makes all lskel tests to be signed tests ?
It's great that CI green lights it, but imo it's an overkill.
Let's have a few signed tests instead of making all of them.
^ permalink raw reply
* Re: [PATCH v2 13/13] selftests/bpf: Add test for signed programs
From: Alexei Starovoitov @ 2025-07-29 2:30 UTC (permalink / raw)
To: KP Singh
Cc: bpf, LSM List, Blaise Boscaccy, Paul Moore, K. Y. Srinivasan,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko
In-Reply-To: <20250721211958.1881379-14-kpsingh@kernel.org>
On Mon, Jul 21, 2025 at 2:20 PM KP Singh <kpsingh@kernel.org> wrote:
> +
> +SEC("fexit/bpf_prog_verify_signature")
> +int BPF_PROG(bpf_sign, struct bpf_prog *prog, union bpf_attr *attr, bool is_kernel, int ret)
I don't understand why it needs to peek into the kernel to
verify that it goes well. The exposed uapi should be good enough.
If the signature was specified and it is loaded fine we're good.
Double checking the kernel decisions goes too far.
Especially since this function can be inlined by the compiler.
^ permalink raw reply
* Re: [PATCH v2 2/3] lockdown/kunit: Introduce kunit tests
From: kernel test robot @ 2025-07-29 7:30 UTC (permalink / raw)
To: Nikolay Borisov, linux-security-module
Cc: oe-kbuild-all, linux-kernel, paul, serge, jmorris, dan.j.williams,
Nikolay Borisov
In-Reply-To: <20250728111517.134116-3-nik.borisov@suse.com>
Hi Nikolay,
kernel test robot noticed the following build errors:
[auto build test ERROR on linus/master]
[also build test ERROR on v6.16 next-20250728]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Nikolay-Borisov/lockdown-Switch-implementation-to-using-bitmap/20250728-191807
base: linus/master
patch link: https://lore.kernel.org/r/20250728111517.134116-3-nik.borisov%40suse.com
patch subject: [PATCH v2 2/3] lockdown/kunit: Introduce kunit tests
config: i386-randconfig-004-20250729 (https://download.01.org/0day-ci/archive/20250729/202507291419.PQ4uKtRo-lkp@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14+deb12u1) 12.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250729/202507291419.PQ4uKtRo-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202507291419.PQ4uKtRo-lkp@intel.com/
All errors (new ones prefixed by >>, old ones prefixed by <<):
WARNING: modpost: missing MODULE_DESCRIPTION() in security/lockdown/lockdown_test.o
>> ERROR: modpost: "lock_kernel_down" [security/lockdown/lockdown_test.ko] undefined!
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v2 2/3] lockdown/kunit: Introduce kunit tests
From: Nikolay Borisov @ 2025-07-29 7:46 UTC (permalink / raw)
To: kernel test robot, linux-security-module
Cc: llvm, oe-kbuild-all, linux-kernel, paul, serge, jmorris,
dan.j.williams
In-Reply-To: <202507290540.9IANrMED-lkp@intel.com>
On 29.07.25 г. 1:04 ч., kernel test robot wrote:
> Hi Nikolay,
>
> kernel test robot noticed the following build warnings:
>
> [auto build test WARNING on linus/master]
> [also build test WARNING on v6.16 next-20250728]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch#_base_tree_information]
>
> url: https://github.com/intel-lab-lkp/linux/commits/Nikolay-Borisov/lockdown-Switch-implementation-to-using-bitmap/20250728-191807
> base: linus/master
> patch link: https://lore.kernel.org/r/20250728111517.134116-3-nik.borisov%40suse.com
> patch subject: [PATCH v2 2/3] lockdown/kunit: Introduce kunit tests
> config: arm-randconfig-004-20250729 (https://download.01.org/0day-ci/archive/20250729/202507290540.9IANrMED-lkp@intel.com/config)
> compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project 1b4db78d2eaa070b3f364a2d2b2b826a5439b892)
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250729/202507290540.9IANrMED-lkp@intel.com/reproduce)
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202507290540.9IANrMED-lkp@intel.com/
>
> All warnings (new ones prefixed by >>):
>
>>> security/lockdown/lockdown.c:31:5: warning: no previous prototype for function 'lock_kernel_down' [-Wmissing-prototypes]
> 31 | int lock_kernel_down(const char *where, enum lockdown_reason level)
> | ^
> security/lockdown/lockdown.c:31:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
> 31 | int lock_kernel_down(const char *where, enum lockdown_reason level)
> | ^
> | static
> 1 warning generated.
That's a false positive, since the function is exported only for KUNIT
case, what's the correct way to make testbot ignore it ?
>
>
> vim +/lock_kernel_down +31 security/lockdown/lockdown.c
>
> 20
> 21 static const enum lockdown_reason lockdown_levels[] = {LOCKDOWN_NONE,
> 22 LOCKDOWN_INTEGRITY_MAX,
> 23 LOCKDOWN_CONFIDENTIALITY_MAX};
> 24
> 25 /*
> 26 * Put the kernel into lock-down mode.
> 27 */
> 28 #if !IS_ENABLED(CONFIG_KUNIT)
> 29 static
> 30 #endif
> > 31 int lock_kernel_down(const char *where, enum lockdown_reason level)
> 32 {
> 33
> 34 if (level > LOCKDOWN_CONFIDENTIALITY_MAX)
> 35 return -EINVAL;
> 36
> 37 if (level == LOCKDOWN_INTEGRITY_MAX || level == LOCKDOWN_CONFIDENTIALITY_MAX)
> 38 bitmap_set(kernel_locked_down, 1, level);
> 39 else
> 40 bitmap_set(kernel_locked_down, level, 1);
> 41
> 42 pr_notice("Kernel is locked down from %s; see man kernel_lockdown.7\n",
> 43 where);
> 44 return 0;
> 45 }
> 46
>
^ permalink raw reply
* Re: [PATCH v4 1/4] arm64: Handle KCOV __init vs inline mismatches
From: Will Deacon @ 2025-07-29 8:10 UTC (permalink / raw)
To: Kees Cook
Cc: Arnd Bergmann, Ard Biesheuvel, Catalin Marinas, Jonathan Cameron,
Gavin Shan, Russell King (Oracle), James Morse, Oza Pawandeep,
Anshuman Khandual, linux-arm-kernel, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Paolo Bonzini,
Mike Rapoport, Vitaly Kuznetsov, Henrique de Moraes Holschuh,
Hans de Goede, Ilpo Järvinen, Rafael J. Wysocki, Len Brown,
Masami Hiramatsu, Michal Wilczynski, Juergen Gross,
Andy Shevchenko, Kirill A. Shutemov, Roger Pau Monne,
David Woodhouse, Usama Arif, Guilherme G. Piccoli, Thomas Huth,
Brian Gerst, Marco Elver, Andrey Konovalov, Andrey Ryabinin,
Hou Wenlong, Andrew Morton, Masahiro Yamada,
Peter Zijlstra (Intel), Luis Chamberlain, Sami Tolvanen,
Christophe Leroy, Nathan Chancellor, Nicolas Schier,
Gustavo A. R. Silva, Andy Lutomirski, Baoquan He, Alexander Graf,
Changyuan Lyu, Paul Moore, James Morris, Serge E. Hallyn,
Nick Desaulniers, Bill Wendling, Justin Stitt, Jan Beulich,
Boqun Feng, Viresh Kumar, Paul E. McKenney, Bibo Mao,
linux-kernel, x86, kvm, ibm-acpi-devel, platform-driver-x86,
linux-acpi, linux-trace-kernel, linux-efi, linux-mm, kasan-dev,
linux-kbuild, linux-hardening, kexec, linux-security-module, llvm
In-Reply-To: <20250724055029.3623499-1-kees@kernel.org>
On Wed, Jul 23, 2025 at 10:50:25PM -0700, Kees Cook wrote:
> GCC appears to have kind of fragile inlining heuristics, in the
> sense that it can change whether or not it inlines something based on
> optimizations. It looks like the kcov instrumentation being added (or in
> this case, removed) from a function changes the optimization results,
> and some functions marked "inline" are _not_ inlined. In that case,
> we end up with __init code calling a function not marked __init, and we
> get the build warnings I'm trying to eliminate in the coming patch that
> adds __no_sanitize_coverage to __init functions:
>
> WARNING: modpost: vmlinux: section mismatch in reference: acpi_get_enable_method+0x1c (section: .text.unlikely) -> acpi_psci_present (section: .init.text)
>
> This problem is somewhat fragile (though using either __always_inline
> or __init will deterministically solve it), but we've tripped over
> this before with GCC and the solution has usually been to just use
> __always_inline and move on.
>
> For arm64 this requires forcing one ACPI function to be inlined with
> __always_inline.
>
> Signed-off-by: Kees Cook <kees@kernel.org>
> ---
> Cc: Will Deacon <will@kernel.org>
> Cc: Ard Biesheuvel <ardb@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> Cc: Gavin Shan <gshan@redhat.com>
> Cc: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>
> Cc: James Morse <james.morse@arm.com>
> Cc: Oza Pawandeep <quic_poza@quicinc.com>
> Cc: Anshuman Khandual <anshuman.khandual@arm.com>
> Cc: <linux-arm-kernel@lists.infradead.org>
> ---
> arch/arm64/include/asm/acpi.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> index a407f9cd549e..c07a58b96329 100644
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -150,7 +150,7 @@ acpi_set_mailbox_entry(int cpu, struct acpi_madt_generic_interrupt *processor)
> {}
> #endif
>
> -static inline const char *acpi_get_enable_method(int cpu)
> +static __always_inline const char *acpi_get_enable_method(int cpu)
> {
> if (acpi_psci_present())
> return "psci";
Thanks for improving the commit message:
Acked-by: Will Deacon <will@kernel.org>
Will
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox