[PATCH v2 0/3] Allow individual features to be locked down

[PATCH v2 0/3] Allow individual features to be locked down

[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

[PATCH v2 1/3] lockdown: Switch implementation to using bitmap

[Nikolay Borisov]

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

[PATCH v2 2/3] lockdown/kunit: Introduce kunit tests

[Nikolay Borisov]

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

[PATCH v2 3/3] lockdown: Use snprintf in lockdown_read

[Nikolay Borisov]

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

Re: [PATCH v2 3/3] lockdown: Use snprintf in lockdown_read

[Serge E. Hallyn]

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
> 

Re: [PATCH v2 1/3] lockdown: Switch implementation to using bitmap

[Serge E. Hallyn]

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
> 

Re: [PATCH v2 2/3] lockdown/kunit: Introduce kunit tests

[Serge E. Hallyn]

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
> 

Re: [PATCH v2 1/3] lockdown: Switch implementation to using bitmap

[Serge E. Hallyn]

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
> 

Re: [PATCH v2 2/3] lockdown/kunit: Introduce kunit tests

[kernel test robot]

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

Re: [PATCH v2 2/3] lockdown/kunit: Introduce kunit tests

[kernel test robot]

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

Re: [PATCH v2 2/3] lockdown/kunit: Introduce kunit tests

[Nikolay Borisov]

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	
> 

Re: [PATCH v2 0/3] Allow individual features to be locked down

[Nicolas Bouchinet]

Hi Nikolay,

Thanks for you patch.

Quoting Kees [1], Lockdown is "about creating a bright line between
uid-0 and ring-0".

Having a bitmap enabled Lockdown would mean that Lockdown reasons could
be activated independently. I fear this would lead to a false sense of
security, locking one reason alone often permits Lockdown restrictions
bypass. i.e enforcing kernel module signature verification but not
blocking accesses to `/dev/{k,}mem` or authorizing gkdb which can be
used to disable the module signature enforcement.

If one wants to restrict accesses to `/dev/mem`,
`security_locked_down(LOCKDOWN_DEV_MEM)` should be sufficient.

My understanding of your problem is that this locks too much for your
usecase and you want to restrict reasons of Lockdown independently in
case it has not been enabled in "integrity" mode by default ?

Can you elaborate more on the usecases for COCO ?

[1]: https://lore.kernel.org/all/CAGXu5j+UWQWDacMvvRCke3xUOb7uTkxn=WaHzG4kJTKWh-6tAA@mail.gmail.com/

Best regards,

Nicolas

---

On Mon, Jul 28, 2025 at 02:15:14PM +0300, Nikolay Borisov wrote:
> 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
> 

Re: [PATCH v2 0/3] Allow individual features to be locked down

[Nikolay Borisov]

On 29.07.25 г. 15:16 ч., Nicolas Bouchinet wrote:
> Hi Nikolay,
> 
> Thanks for you patch.
> 
> Quoting Kees [1], Lockdown is "about creating a bright line between
> uid-0 and ring-0".
> 
> Having a bitmap enabled Lockdown would mean that Lockdown reasons could
> be activated independently. I fear this would lead to a false sense of
> security, locking one reason alone often permits Lockdown restrictions
> bypass. i.e enforcing kernel module signature verification but not
> blocking accesses to `/dev/{k,}mem` or authorizing gkdb which can be
> used to disable the module signature enforcement.
> 
> If one wants to restrict accesses to `/dev/mem`,
> `security_locked_down(LOCKDOWN_DEV_MEM)` should be sufficient.
> 
> My understanding of your problem is that this locks too much for your
> usecase and you want to restrict reasons of Lockdown independently in
> case it has not been enabled in "integrity" mode by default ?
> 
> Can you elaborate more on the usecases for COCO ?

Initially this patchset was supposed to allow us selectively disable 
/dev/iomem access in a CoCo context [0]. As evident from Dan's initial 
response that point pretty much became moot as the issue was fixed in a 
different way. However, later [1] he came back and said that actually 
this patch could be useful in a similar context. So This v2 is 
essentially following up on that.


[0] 
https://lore.kernel.org/all/67f69600ed221_71fe2946f@dwillia2-xfh.jf.intel.com.notmuch/

[1] 
https://lore.kernel.org/all/68226ad551afd_29032945b@dwillia2-xfh.jf.intel.com.notmuch/

<snip>

Re: [PATCH v2 2/3] lockdown/kunit: Introduce kunit tests

[Philip Li]

On Tue, Jul 29, 2025 at 10:46:48AM +0300, Nikolay Borisov wrote:
> 
> 
> 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 ?

thanks for the info, i will configure the bot to ignore this firstly, and
later to check whether there's any pattern for more general ignore. Sorry
for the noise.

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

Re: [PATCH v2 0/3] Allow individual features to be locked down

[xiujianfeng]

On 2025/7/29 20:25, Nikolay Borisov wrote:
> 
> 
> On 29.07.25 г. 15:16 ч., Nicolas Bouchinet wrote:
>> Hi Nikolay,
>>
>> Thanks for you patch.
>>
>> Quoting Kees [1], Lockdown is "about creating a bright line between
>> uid-0 and ring-0".
>>
>> Having a bitmap enabled Lockdown would mean that Lockdown reasons could
>> be activated independently. I fear this would lead to a false sense of
>> security, locking one reason alone often permits Lockdown restrictions
>> bypass. i.e enforcing kernel module signature verification but not
>> blocking accesses to `/dev/{k,}mem` or authorizing gkdb which can be
>> used to disable the module signature enforcement.
>>
>> If one wants to restrict accesses to `/dev/mem`,
>> `security_locked_down(LOCKDOWN_DEV_MEM)` should be sufficient.
>>
>> My understanding of your problem is that this locks too much for your
>> usecase and you want to restrict reasons of Lockdown independently in
>> case it has not been enabled in "integrity" mode by default ?
>>
>> Can you elaborate more on the usecases for COCO ?
> 
> Initially this patchset was supposed to allow us selectively disable
> /dev/iomem access in a CoCo context [0]. As evident from Dan's initial
> response that point pretty much became moot as the issue was fixed in a
> different way. However, later [1] he came back and said that actually
> this patch could be useful in a similar context. So This v2 is
> essentially following up on that.

Hi Nikolay,

I share a similar view with Nicolas, namely that using a bitmap
implementation would compromise the goal of Lockdown.

After reading the threads below, I understand you aim is to block user
access to /dev/mem, but without having Lockdown integrity mode enabled
to block other reasons, right? How about using BPF LSM? It seems it
could address your requirements.

> 
> 
> [0]
> https://lore.kernel.org/all/67f69600ed221_71fe2946f@dwillia2-xfh.jf.intel.com.notmuch/
> 
> [1]
> https://lore.kernel.org/all/68226ad551afd_29032945b@dwillia2-xfh.jf.intel.com.notmuch/
> 
> <snip>

Re: [PATCH v2 3/3] lockdown: Use snprintf in lockdown_read

[Nikolay Borisov]

On 7/28/25 15:39, Serge E. Hallyn wrote:
> 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).

ack

> 
>> +
>>
>>   			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?

Indeed, I was wondering the same when writing the code initially. I 
guess either einval/e2big are both well fitted in this case. If I had to 
choose I'd likely go with E2BIG since it's less prevalent than einval 
and if someone changes the implementation and starts getting E2BIG it 
should be easier to spot where it's coming from. That'd be my only 
consideration between the 2.

However, given that this series seems to be unconvincing for the 
maintainer I'll defer those changes until it's decided that it's 
eventually getting merged :)

> 
>> +
>> +			offset += ret;
>>   		}
>>   	}
>>
>> --
>> 2.34.1
>>

Re: [PATCH v2 0/3] Allow individual features to be locked down

[Nikolay Borisov]

On 8/5/25 09:57, xiujianfeng wrote:
> 
> 
> On 2025/7/29 20:25, Nikolay Borisov wrote:
>>
>>
>> On 29.07.25 г. 15:16 ч., Nicolas Bouchinet wrote:
>>> Hi Nikolay,
>>>
>>> Thanks for you patch.
>>>
>>> Quoting Kees [1], Lockdown is "about creating a bright line between
>>> uid-0 and ring-0".
>>>
>>> Having a bitmap enabled Lockdown would mean that Lockdown reasons could
>>> be activated independently. I fear this would lead to a false sense of
>>> security, locking one reason alone often permits Lockdown restrictions
>>> bypass. i.e enforcing kernel module signature verification but not
>>> blocking accesses to `/dev/{k,}mem` or authorizing gkdb which can be
>>> used to disable the module signature enforcement.
>>>
>>> If one wants to restrict accesses to `/dev/mem`,
>>> `security_locked_down(LOCKDOWN_DEV_MEM)` should be sufficient.
>>>
>>> My understanding of your problem is that this locks too much for your
>>> usecase and you want to restrict reasons of Lockdown independently in
>>> case it has not been enabled in "integrity" mode by default ?
>>>
>>> Can you elaborate more on the usecases for COCO ?
>>
>> Initially this patchset was supposed to allow us selectively disable
>> /dev/iomem access in a CoCo context [0]. As evident from Dan's initial
>> response that point pretty much became moot as the issue was fixed in a
>> different way. However, later [1] he came back and said that actually
>> this patch could be useful in a similar context. So This v2 is
>> essentially following up on that.
> 
> Hi Nikolay,
> 
> I share a similar view with Nicolas, namely that using a bitmap
> implementation would compromise the goal of Lockdown.
> 
> After reading the threads below, I understand you aim is to block user
> access to /dev/mem, but without having Lockdown integrity mode enabled
> to block other reasons, right? How about using BPF LSM? It seems it
> could address your requirements.
> 

Well the use case that my change allows  (barring the original issue) is 
say if someone wants LOCKDOWN_INTEGRITY_MAX + 1 or 2 things from the 
CONFIDENTIALY_MAX level.

>>
>>
>> [0]
>> https://lore.kernel.org/all/67f69600ed221_71fe2946f@dwillia2-xfh.jf.intel.com.notmuch/
>>
>> [1]
>> https://lore.kernel.org/all/68226ad551afd_29032945b@dwillia2-xfh.jf.intel.com.notmuch/
>>
>> <snip>

Re: [PATCH v2 1/3] lockdown: Switch implementation to using bitmap

[dan.j.williams]

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;

So now attempts to reduce security return "success" where previously
they get permission denied?

I think that is an unforunate side effect of trying to have this one
function handle both levels and individual features.

> -	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);
> +

The individual case probably deserves its own interface given all
current kernels expect levels and the future callers probably want to
skip the pr_notice() below given only piecemeal features are being
disabled.

You might even special case just LOCKDOWN_DEV_MEM for now as the only
once that can be indepdently set by an internal caller.

Re: [PATCH v2 3/3] lockdown: Use snprintf in lockdown_read

[dan.j.williams]

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.

I would have expected this safety to come before patch1, but it also
feels like the maximum buffer size could be calculated at compile time
to make the maximum output always fit.

Re: [PATCH v2 0/3] Allow individual features to be locked down

[dan.j.williams]

xiujianfeng wrote:
> 
> 
> On 2025/7/29 20:25, Nikolay Borisov wrote:
> > 
> > 
> > On 29.07.25 г. 15:16 ч., Nicolas Bouchinet wrote:
> >> Hi Nikolay,
> >>
> >> Thanks for you patch.
> >>
> >> Quoting Kees [1], Lockdown is "about creating a bright line between
> >> uid-0 and ring-0".
> >>
> >> Having a bitmap enabled Lockdown would mean that Lockdown reasons could
> >> be activated independently. I fear this would lead to a false sense of
> >> security, locking one reason alone often permits Lockdown restrictions
> >> bypass. i.e enforcing kernel module signature verification but not
> >> blocking accesses to `/dev/{k,}mem` or authorizing gkdb which can be
> >> used to disable the module signature enforcement.
> >>
> >> If one wants to restrict accesses to `/dev/mem`,
> >> `security_locked_down(LOCKDOWN_DEV_MEM)` should be sufficient.
> >>
> >> My understanding of your problem is that this locks too much for your
> >> usecase and you want to restrict reasons of Lockdown independently in
> >> case it has not been enabled in "integrity" mode by default ?
> >>
> >> Can you elaborate more on the usecases for COCO ?
> > 
> > Initially this patchset was supposed to allow us selectively disable
> > /dev/iomem access in a CoCo context [0]. As evident from Dan's initial
> > response that point pretty much became moot as the issue was fixed in a
> > different way. However, later [1] he came back and said that actually
> > this patch could be useful in a similar context. So This v2 is
> > essentially following up on that.
> 
> Hi Nikolay,
> 
> I share a similar view with Nicolas, namely that using a bitmap
> implementation would compromise the goal of Lockdown.
> 
> After reading the threads below, I understand you aim is to block user
> access to /dev/mem, but without having Lockdown integrity mode enabled
> to block other reasons, right? How about using BPF LSM? It seems it
> could address your requirements.

BPF LSM does not seem suitable for the main concern which is that arch
code needs hard guarantess that certain code paths are disabled. For
Confidential Computing it needs to know that userspace access of
/dev/mem is always disabled.

This is a functional concern, not a security concern. Both Arnd [1] and
Greg [2] lamented needing new hacks to achieve the same outcome as just
reusing the existing security_locked_down() checks. The
SECURITY_LOCKDOWN_LSM already has /sys/kernel/security/lockdown ABI for
communicating built-in and now kernel-internal sources of locked
functionality.

[1]: http://lore.kernel.org/0bdb1876-0cb3-4632-910b-2dc191902e3e@app.fastmail.com
[2]: http://lore.kernel.org/2025043025-cathouse-headlamp-7bde@gregkh

Re: [PATCH v2 0/3] Allow individual features to be locked down

[dan.j.williams]

Nicolas Bouchinet wrote:
> Hi Nikolay,
> 
> Thanks for you patch.
> 
> Quoting Kees [1], Lockdown is "about creating a bright line between
> uid-0 and ring-0".
> 
> Having a bitmap enabled Lockdown would mean that Lockdown reasons could
> be activated independently. I fear this would lead to a false sense of
> security, locking one reason alone often permits Lockdown restrictions
> bypass. i.e enforcing kernel module signature verification but not
> blocking accesses to `/dev/{k,}mem` or authorizing gkdb which can be
> used to disable the module signature enforcement.
> 
> If one wants to restrict accesses to `/dev/mem`,
> `security_locked_down(LOCKDOWN_DEV_MEM)` should be sufficient.
> 
> My understanding of your problem is that this locks too much for your
> usecase and you want to restrict reasons of Lockdown independently in
> case it has not been enabled in "integrity" mode by default ?
> 
> Can you elaborate more on the usecases for COCO ?

Nikolay already shared some of this but the succinct answer is that COCO
breaks the fundamental expectations of /dev/mem that the only
requirement to map memory is to install a page table entry for it.

For COCO an additional step is needed to decide if the memory is private
to the COCO guest VM (cVM) or shared with the host VMM. If it is private
it additionally must be "accepted" by the cVM before it can be mapped.

/dev/mem allows uncoordinated mapping attempts and at present causes
memory protection violations because the /dev/mem backend attetmps to
map it as shared, but another part of the kernel expects it is only
mapped as cVM-private.

The attempt to communicate the mapping type, control for the acceptance
status resulted in a pile of hacks, or even just add another
COCO-specific check near the existing
"security_locked_down(LOCKDOWN_DEV_MEM)" check were met with "please
just use LOCKDOWN_DEV_MEM" directly and be done.

Re: [PATCH v2 0/3] Allow individual features to be locked down

[Nicolas Bouchinet]

Hi Nikolay,

After discussing with Xiu, we have decided not to accept this patchset.

The goal of Lockdown being to draw a clear line between ring-0 and uid-0,
having a more granular way to activate Lockdown will break it. Primarily
because most lockdown-reasons can be bypassed if used independently.

Even if the goal of Lockdown were to be redefined, we would need to ensure the
security interdependence between different lockdown-reasons. This is highly
tied to where people calls the `security_locked_down` hook and thus is out of
our maintenance scope.

Having coarse-grained lockdown reasons and integrity/confidentiality levels
allows us to ensure that all of the reasons are correctly locked down.

Best regards,

Nicolas

Re: [PATCH v2 0/3] Allow individual features to be locked down

[Nikolay Borisov]

On 8/14/25 11:59, Nicolas Bouchinet wrote:
> Hi Nikolay,
> 
> After discussing with Xiu, we have decided not to accept this patchset.
> 
> The goal of Lockdown being to draw a clear line between ring-0 and uid-0,
> having a more granular way to activate Lockdown will break it. Primarily
> because most lockdown-reasons can be bypassed if used independently.
> 
> Even if the goal of Lockdown were to be redefined, we would need to ensure the
> security interdependence between different lockdown-reasons. This is highly
> tied to where people calls the `security_locked_down` hook and thus is out of
> our maintenance scope.
> 
> Having coarse-grained lockdown reasons and integrity/confidentiality levels
> allows us to ensure that all of the reasons are correctly locked down.
> 
> Best regards,
> 
> Nicolas

Thanks for the feedback, to try and not have all this code go to waste, 
what about consdering patch 2 - kunits tests. Apart from 
lockdown_test_individual_level() the other tests are applicable to the 
existing lockdown implementation and can aid in future developments?

Re: [PATCH v2 0/3] Allow individual features to be locked down

[Nicolas Bouchinet]

On Thu, Aug 14, 2025 at 01:02:36PM +0300, Nikolay Borisov wrote:
> 
> 
> On 8/14/25 11:59, Nicolas Bouchinet wrote:
> > Hi Nikolay,
> > 
> > After discussing with Xiu, we have decided not to accept this patchset.
> > 
> > The goal of Lockdown being to draw a clear line between ring-0 and uid-0,
> > having a more granular way to activate Lockdown will break it. Primarily
> > because most lockdown-reasons can be bypassed if used independently.
> > 
> > Even if the goal of Lockdown were to be redefined, we would need to ensure the
> > security interdependence between different lockdown-reasons. This is highly
> > tied to where people calls the `security_locked_down` hook and thus is out of
> > our maintenance scope.
> > 
> > Having coarse-grained lockdown reasons and integrity/confidentiality levels
> > allows us to ensure that all of the reasons are correctly locked down.
> > 
> > Best regards,
> > 
> > Nicolas
> 
> Thanks for the feedback, to try and not have all this code go to waste, what
> about consdering patch 2 - kunits tests. Apart from
> lockdown_test_individual_level() the other tests are applicable to the
> existing lockdown implementation and can aid in future developments?
> 

Yes of course, thanks a lot for those tests. Can you adapt them and send
them separately for review ?

i.e, the `lockdown_test_no_downgrade` should check for -EPERM.

FYI, I have a three week holiday starting today. I'll return on
Septembre the 8th. I let Xiu review those patches until then.