[PATCH 0/3] mseal sysmap: Choose system mapping sealing at boot

[PATCH 0/3] mseal sysmap: Choose system mapping sealing at boot

[Chris Down]

System mapping sealing is currently a build time choice. Hosts which
want it and hosts which need to move or unmap these mappings therefore
need separate kernels, which is not ideal. Let's allow the administrator
to choose at boot time.

Chris Down (3):
  mseal sysmap: Add mseal_system_mappings= boot parameter
  mseal sysmap: Allow with CHECKPOINT_RESTORE, default off
  selftests/mseal_system_mappings: Test vdso unmap and remap

 .../admin-guide/kernel-parameters.txt         |   7 +
 Documentation/userspace-api/mseal.rst         |   5 +-
 include/linux/mm.h                            |   3 +-
 mm/mseal.c                                    |  13 +
 security/Kconfig                              |  17 +-
 .../selftests/mseal_system_mappings/Makefile  |   2 +
 .../selftests/mseal_system_mappings/config    |   2 +
 .../mseal_system_mappings/sysmap_is_sealed.c  | 236 ++++++++++++++++--
 8 files changed, 268 insertions(+), 17 deletions(-)


base-commit: bae9a042b03b27924c6fd5bdc00a20d6a44d6041
-- 
2.54.0

[PATCH 1/3] mseal sysmap: Add mseal_system_mappings= boot parameter

[Chris Down]

CONFIG_MSEAL_SYSTEM_MAPPINGS seals each process' system mappings when
they are created. As it is today this can only be toggled at build time,
so hosts that need sealing and hosts running software which moves or
unmaps these mappings end up with separate kernels. This is not ideal
since it adds more complexity of deployment, it would be great to be
able to have one kernel which can configurably do both.

So, to improve this, let's add mseal_system_mappings= so that this can
be chosen at boot.

Signed-off-by: Chris Down <chris@chrisdown.name>
---
 .../admin-guide/kernel-parameters.txt         |   7 ++
 Documentation/userspace-api/mseal.rst         |   3 +-
 include/linux/mm.h                            |   3 +-
 mm/mseal.c                                    |  12 ++
 security/Kconfig                              |   2 +
 .../mseal_system_mappings/sysmap_is_sealed.c  | 104 +++++++++++++++---
 6 files changed, 115 insertions(+), 16 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index e75344f4e0cd..b1ec9a8a979e 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -4270,6 +4270,13 @@ Kernel parameters
 	MTD_Region=	[MTD] Format:
 			<name>,<region-number>[,<base>,<size>,<buswidth>,<altbuswidth>]
 
+	mseal_system_mappings=
+			[KNL,EARLY] Under CONFIG_MSEAL_SYSTEM_MAPPINGS,
+			whether system mappings are sealed for this boot.
+			See Documentation/userspace-api/mseal.rst.
+			Format: <bool>
+			Default: 1 (enabled).
+
 	mtdparts=	[MTD]
 			See drivers/mtd/parsers/cmdlinepart.c
 
diff --git a/Documentation/userspace-api/mseal.rst b/Documentation/userspace-api/mseal.rst
index c039d782f9f5..4e50215e4762 100644
--- a/Documentation/userspace-api/mseal.rst
+++ b/Documentation/userspace-api/mseal.rst
@@ -142,7 +142,8 @@ Use cases
 
   If supported by an architecture (CONFIG_ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS),
   the CONFIG_MSEAL_SYSTEM_MAPPINGS seals all system mappings of this
-  architecture.
+  architecture. The kernel command line parameter
+  ``mseal_system_mappings=0`` turns this off at boot.
 
   WARNING: This feature breaks programs which rely on relocating
   or unmapping system mappings. Known broken software at the time
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 5f82be0fcde5..2329d81b7d46 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -568,7 +568,8 @@ enum {
 #define VM_STACK_FLAGS vma_flags_to_legacy(VMA_STACK_FLAGS)
 
 #ifdef CONFIG_MSEAL_SYSTEM_MAPPINGS
-#define VM_SEALED_SYSMAP	VM_SEALED
+extern bool mseal_sysmap_enabled;
+#define VM_SEALED_SYSMAP	(mseal_sysmap_enabled ? VM_SEALED : VM_NONE)
 #else
 #define VM_SEALED_SYSMAP	VM_NONE
 #endif
diff --git a/mm/mseal.c b/mm/mseal.c
index 7a8ac66dc215..e0563796cfa3 100644
--- a/mm/mseal.c
+++ b/mm/mseal.c
@@ -7,6 +7,8 @@
  *  Author: Jeff Xu <jeffxu@chromium.org>
  */
 
+#include <linux/init.h>
+#include <linux/kstrtox.h>
 #include <linux/mempolicy.h>
 #include <linux/minmax.h>
 #include <linux/mman.h>
@@ -16,6 +18,16 @@
 #include <linux/sched.h>
 #include "internal.h"
 
+#ifdef CONFIG_MSEAL_SYSTEM_MAPPINGS
+bool mseal_sysmap_enabled __ro_after_init = true;
+
+static int __init early_mseal_sysmap(char *buf)
+{
+	return kstrtobool(buf, &mseal_sysmap_enabled);
+}
+early_param("mseal_system_mappings", early_mseal_sysmap);
+#endif
+
 static bool range_contains_unmapped(unsigned long start, unsigned long end)
 {
 	VMA_ITERATOR(vmi, current->mm, start);
diff --git a/security/Kconfig b/security/Kconfig
index f7bf6cdc6229..d5e83af1bfc6 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -67,6 +67,8 @@ config MSEAL_SYSTEM_MAPPINGS
 	  of writing includes CHECKPOINT_RESTORE, UML, gVisor, rr. Therefore
 	  this config can't be enabled universally.
 
+	  Sealing can be turned off at boot with "mseal_system_mappings=0".
+
 	  For complete descriptions of memory sealing, please see
 	  Documentation/userspace-api/mseal.rst
 
diff --git a/tools/testing/selftests/mseal_system_mappings/sysmap_is_sealed.c b/tools/testing/selftests/mseal_system_mappings/sysmap_is_sealed.c
index cb0ca6ed7ebe..97348c2a0689 100644
--- a/tools/testing/selftests/mseal_system_mappings/sysmap_is_sealed.c
+++ b/tools/testing/selftests/mseal_system_mappings/sysmap_is_sealed.c
@@ -1,12 +1,12 @@
 // SPDX-License-Identifier: GPL-2.0-only
 /*
- * test system mappings are sealed when
- * KCONFIG_MSEAL_SYSTEM_MAPPINGS=y
+ * Test system mapping sealing and the mseal_system_mappings= boot parameter.
  */
 
 #define _GNU_SOURCE
 #include <stdio.h>
 #include <errno.h>
+#include <ctype.h>
 #include <unistd.h>
 #include <string.h>
 #include <stdbool.h>
@@ -17,6 +17,73 @@
 #define VMFLAGS "VmFlags:"
 #define MSEAL_FLAGS "sl"
 #define MAX_LINE_LEN 512
+#define SYSMAP_PARAM "mseal_system_mappings="
+
+static int parse_bool(const char *s, bool *res)
+{
+	if (!s)
+		return -EINVAL;
+
+	switch (tolower((unsigned char)s[0])) {
+	case 'e':
+	case 'y':
+	case 't':
+	case '1':
+		*res = true;
+		return 0;
+	case 'd':
+	case 'n':
+	case 'f':
+	case '0':
+		*res = false;
+		return 0;
+	case 'o':
+		switch (tolower((unsigned char)s[1])) {
+		case 'n':
+			*res = true;
+			return 0;
+		case 'f':
+			*res = false;
+			return 0;
+		}
+		break;
+	}
+
+	return -EINVAL;
+}
+
+static int sysmap_sealed_expected(void)
+{
+	char cmdline[4096], *tok, *save;
+	int sealed = 1;
+	bool value;
+	size_t len;
+	FILE *f;
+
+	f = fopen("/proc/cmdline", "r");
+	if (!f)
+		return -1;
+	len = fread(cmdline, 1, sizeof(cmdline) - 1, f);
+	if (ferror(f) || !feof(f)) {
+		fclose(f);
+		return -1;
+	}
+	fclose(f);
+	cmdline[len] = '\0';
+
+	for (tok = strtok_r(cmdline, " \t\n", &save); tok;
+	     tok = strtok_r(NULL, " \t\n", &save)) {
+		if (!strcmp(tok, "--"))
+			break;
+		if (strncmp(tok, SYSMAP_PARAM, strlen(SYSMAP_PARAM)))
+			continue;
+
+		if (!parse_bool(tok + strlen(SYSMAP_PARAM), &value))
+			sealed = value;
+	}
+
+	return sealed;
+}
 
 bool has_mapping(char *name, FILE *maps)
 {
@@ -30,7 +97,7 @@ bool has_mapping(char *name, FILE *maps)
 	return false;
 }
 
-bool mapping_is_sealed(char *name, FILE *maps)
+int mapping_is_sealed(FILE *maps)
 {
 	char line[MAX_LINE_LEN];
 
@@ -43,7 +110,7 @@ bool mapping_is_sealed(char *name, FILE *maps)
 		}
 	}
 
-	return false;
+	return -1;
 }
 
 FIXTURE(basic) {
@@ -67,53 +134,62 @@ FIXTURE_TEARDOWN(basic)
 FIXTURE_VARIANT(basic)
 {
 	char *name;
-	bool sealed;
+	bool sysmap;
 };
 
 FIXTURE_VARIANT_ADD(basic, vdso) {
 	.name = "[vdso]",
-	.sealed = true,
+	.sysmap = true,
 };
 
 FIXTURE_VARIANT_ADD(basic, vvar) {
 	.name = "[vvar]",
-	.sealed = true,
+	.sysmap = true,
 };
 
 FIXTURE_VARIANT_ADD(basic, vvar_vclock) {
 	.name = "[vvar_vclock]",
-	.sealed = true,
+	.sysmap = true,
 };
 
 FIXTURE_VARIANT_ADD(basic, sigpage) {
 	.name = "[sigpage]",
-	.sealed = true,
+	.sysmap = true,
 };
 
 FIXTURE_VARIANT_ADD(basic, vectors) {
 	.name = "[vectors]",
-	.sealed = true,
+	.sysmap = true,
 };
 
 FIXTURE_VARIANT_ADD(basic, uprobes) {
 	.name = "[uprobes]",
-	.sealed = true,
+	.sysmap = true,
 };
 
 FIXTURE_VARIANT_ADD(basic, stack) {
 	.name = "[stack]",
-	.sealed = false,
+	.sysmap = false,
 };
 
 TEST_F(basic, check_sealed)
 {
+	int expected = 0, sealed;
+
 	if (!has_mapping(variant->name, self->maps)) {
 		SKIP(return, "could not find the mapping, %s",
 			variant->name);
 	}
 
-	EXPECT_EQ(variant->sealed,
-		mapping_is_sealed(variant->name, self->maps));
+	sealed = mapping_is_sealed(self->maps);
+	if (sealed < 0)
+		SKIP(return, "could not read the mapping's sealing state");
+	if (variant->sysmap) {
+		expected = sysmap_sealed_expected();
+		if (expected < 0)
+			SKIP(return, "could not determine the expected sealing state");
+	}
+	EXPECT_EQ(expected, sealed);
 };
 
 TEST_HARNESS_MAIN
-- 
2.54.0

Re: [PATCH 1/3] mseal sysmap: Add mseal_system_mappings= boot parameter

[Lorenzo Stoakes (ARM)]

The existing implementation is a bit of a mess, so any work that extends it
has to put in the work to improve things first.

I _hate_ VM_SEALED_SYSMAP. It's a hack. A tasteful way of doing this is
really required for a series touching this to be taken, honestly.

See below for implementation ideas.

(Also it's the merge window, so no more revisions until -rc1, when you need
to resend, thanks.)

On Tue, Oct 27, 2026 at 07:43:04PM +0800, Chris Down wrote:
> CONFIG_MSEAL_SYSTEM_MAPPINGS seals each process' system mappings when
> they are created. As it is today this can only be toggled at build time,
> so hosts that need sealing and hosts running software which moves or
> unmaps these mappings end up with separate kernels. This is not ideal
> since it adds more complexity of deployment, it would be great to be
> able to have one kernel which can configurably do both.

Could we have some actual justification for the use of the feature please?
So far I've seen arm-waving.

>
> So, to improve this, let's add mseal_system_mappings= so that this can
> be chosen at boot.
>
> Signed-off-by: Chris Down <chris@chrisdown.name>
> ---
>  .../admin-guide/kernel-parameters.txt         |   7 ++
>  Documentation/userspace-api/mseal.rst         |   3 +-
>  include/linux/mm.h                            |   3 +-
>  mm/mseal.c                                    |  12 ++
>  security/Kconfig                              |   2 +
>  .../mseal_system_mappings/sysmap_is_sealed.c  | 104 +++++++++++++++---
>  6 files changed, 115 insertions(+), 16 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index e75344f4e0cd..b1ec9a8a979e 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -4270,6 +4270,13 @@ Kernel parameters
>  	MTD_Region=	[MTD] Format:
>  			<name>,<region-number>[,<base>,<size>,<buswidth>,<altbuswidth>]
>
> +	mseal_system_mappings=
> +			[KNL,EARLY] Under CONFIG_MSEAL_SYSTEM_MAPPINGS,
> +			whether system mappings are sealed for this boot.
> +			See Documentation/userspace-api/mseal.rst.
> +			Format: <bool>
> +			Default: 1 (enabled).

You _have_ to duplicate the list of things this breaks here please.

> +
>  	mtdparts=	[MTD]
>  			See drivers/mtd/parsers/cmdlinepart.c
>
> diff --git a/Documentation/userspace-api/mseal.rst b/Documentation/userspace-api/mseal.rst
> index c039d782f9f5..4e50215e4762 100644
> --- a/Documentation/userspace-api/mseal.rst
> +++ b/Documentation/userspace-api/mseal.rst
> @@ -142,7 +142,8 @@ Use cases
>
>    If supported by an architecture (CONFIG_ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS),
>    the CONFIG_MSEAL_SYSTEM_MAPPINGS seals all system mappings of this
> -  architecture.
> +  architecture. The kernel command line parameter
> +  ``mseal_system_mappings=0`` turns this off at boot.

This is just really confusing.

Adding a flag that defaults to on but only defaults to on if the config
option is enabled...

Let's just refactor this properly to stop abusing a 'VMA flag' (which is
really not a VMA flag, but an alias).

Let's negate things first. Make the boot flag 'no_mseal_sys_mappings'
rather than confusingly implying mseal_system_mappings=1 could enable it
even with a config option not provided.

Then add something like:

static inline bool mseal_system_mappings(void)
{
        return IS_ENABLED(CONFIG_MSEAL_SYSTEM_MAPPINGS) &&
               !mseal_system_mappings_disabled;
}

And call that in _install_special_mapping().

The LLM overlords tell me that only uprobe trampolines would see a delta
from this given the ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS restriction.

This would improve things a lot.

>
>    WARNING: This feature breaks programs which rely on relocating
>    or unmapping system mappings. Known broken software at the time
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 5f82be0fcde5..2329d81b7d46 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -568,7 +568,8 @@ enum {
>  #define VM_STACK_FLAGS vma_flags_to_legacy(VMA_STACK_FLAGS)
>
>  #ifdef CONFIG_MSEAL_SYSTEM_MAPPINGS
> -#define VM_SEALED_SYSMAP	VM_SEALED
> +extern bool mseal_sysmap_enabled;
> +#define VM_SEALED_SYSMAP	(mseal_sysmap_enabled ? VM_SEALED : VM_NONE)

No, you don't use the legacy VMA flags API for new work. Sorry.

See above as to a pointer as to how this should look.

>  #else
>  #define VM_SEALED_SYSMAP	VM_NONE
>  #endif
> diff --git a/mm/mseal.c b/mm/mseal.c
> index 7a8ac66dc215..e0563796cfa3 100644
> --- a/mm/mseal.c
> +++ b/mm/mseal.c
> @@ -7,6 +7,8 @@
>   *  Author: Jeff Xu <jeffxu@chromium.org>
>   */
>
> +#include <linux/init.h>
> +#include <linux/kstrtox.h>
>  #include <linux/mempolicy.h>
>  #include <linux/minmax.h>
>  #include <linux/mman.h>
> @@ -16,6 +18,16 @@
>  #include <linux/sched.h>
>  #include "internal.h"
>
> +#ifdef CONFIG_MSEAL_SYSTEM_MAPPINGS
> +bool mseal_sysmap_enabled __ro_after_init = true;

See above re: rework of this.

> +
> +static int __init early_mseal_sysmap(char *buf)
> +{
> +	return kstrtobool(buf, &mseal_sysmap_enabled);
> +}
> +early_param("mseal_system_mappings", early_mseal_sysmap);
> +#endif
> +
>  static bool range_contains_unmapped(unsigned long start, unsigned long end)
>  {
>  	VMA_ITERATOR(vmi, current->mm, start);
> diff --git a/security/Kconfig b/security/Kconfig
> index f7bf6cdc6229..d5e83af1bfc6 100644
> --- a/security/Kconfig
> +++ b/security/Kconfig
> @@ -67,6 +67,8 @@ config MSEAL_SYSTEM_MAPPINGS
>  	  of writing includes CHECKPOINT_RESTORE, UML, gVisor, rr. Therefore
>  	  this config can't be enabled universally.
>
> +	  Sealing can be turned off at boot with "mseal_system_mappings=0".
> +

'With this configuration option set, sealing can...' right now this reads a
little like it's defaulted on.

Also can we move this Kconfig option out of security and into mm please?
This is explicitly an mm feature, and it should never have been added there
(mm needs to know if somebody sets this default=y or something for
instance).

In any case, as above, no_mseal_sys_mappings is probably a better way, then
this becomes something like:

"With this configuration option set, the feature can be disabled
with the no_mseal_sys_mappings boot parameter.'

>  	  For complete descriptions of memory sealing, please see
>  	  Documentation/userspace-api/mseal.rst
>
> diff --git a/tools/testing/selftests/mseal_system_mappings/sysmap_is_sealed.c b/tools/testing/selftests/mseal_system_mappings/sysmap_is_sealed.c
> index cb0ca6ed7ebe..97348c2a0689 100644
> --- a/tools/testing/selftests/mseal_system_mappings/sysmap_is_sealed.c
> +++ b/tools/testing/selftests/mseal_system_mappings/sysmap_is_sealed.c

Tests as separate commits please.

> @@ -1,12 +1,12 @@
>  // SPDX-License-Identifier: GPL-2.0-only
>  /*
> - * test system mappings are sealed when
> - * KCONFIG_MSEAL_SYSTEM_MAPPINGS=y
> + * Test system mapping sealing and the mseal_system_mappings= boot parameter.
>   */

Can we have test changes as separate commits please.

>
>  #define _GNU_SOURCE
>  #include <stdio.h>
>  #include <errno.h>
> +#include <ctype.h>
>  #include <unistd.h>
>  #include <string.h>
>  #include <stdbool.h>
> @@ -17,6 +17,73 @@
>  #define VMFLAGS "VmFlags:"
>  #define MSEAL_FLAGS "sl"
>  #define MAX_LINE_LEN 512
> +#define SYSMAP_PARAM "mseal_system_mappings="
> +
> +static int parse_bool(const char *s, bool *res)
> +{
> +	if (!s)
> +		return -EINVAL;
> +
> +	switch (tolower((unsigned char)s[0])) {
> +	case 'e':
> +	case 'y':
> +	case 't':
> +	case '1':
> +		*res = true;
> +		return 0;
> +	case 'd':
> +	case 'n':
> +	case 'f':
> +	case '0':
> +		*res = false;
> +		return 0;
> +	case 'o':
> +		switch (tolower((unsigned char)s[1])) {
> +		case 'n':
> +			*res = true;
> +			return 0;
> +		case 'f':
> +			*res = false;
> +			return 0;
> +		}
> +		break;
> +	}
> +
> +	return -EINVAL;
> +}
> +
> +static int sysmap_sealed_expected(void)
> +{
> +	char cmdline[4096], *tok, *save;
> +	int sealed = 1;
> +	bool value;
> +	size_t len;
> +	FILE *f;
> +
> +	f = fopen("/proc/cmdline", "r");
> +	if (!f)
> +		return -1;
> +	len = fread(cmdline, 1, sizeof(cmdline) - 1, f);
> +	if (ferror(f) || !feof(f)) {
> +		fclose(f);
> +		return -1;
> +	}
> +	fclose(f);
> +	cmdline[len] = '\0';
> +
> +	for (tok = strtok_r(cmdline, " \t\n", &save); tok;
> +	     tok = strtok_r(NULL, " \t\n", &save)) {
> +		if (!strcmp(tok, "--"))
> +			break;
> +		if (strncmp(tok, SYSMAP_PARAM, strlen(SYSMAP_PARAM)))
> +			continue;
> +
> +		if (!parse_bool(tok + strlen(SYSMAP_PARAM), &value))
> +			sealed = value;
> +	}
> +
> +	return sealed;
> +}

This seems total overkill, you're checking whether a boot parameter works?

>
>  bool has_mapping(char *name, FILE *maps)
>  {
> @@ -30,7 +97,7 @@ bool has_mapping(char *name, FILE *maps)
>  	return false;
>  }
>
> -bool mapping_is_sealed(char *name, FILE *maps)
> +int mapping_is_sealed(FILE *maps)
>  {
>  	char line[MAX_LINE_LEN];
>
> @@ -43,7 +110,7 @@ bool mapping_is_sealed(char *name, FILE *maps)
>  		}
>  	}
>
> -	return false;
> +	return -1;
>  }
>
>  FIXTURE(basic) {
> @@ -67,53 +134,62 @@ FIXTURE_TEARDOWN(basic)
>  FIXTURE_VARIANT(basic)
>  {
>  	char *name;
> -	bool sealed;
> +	bool sysmap;
>  };
>
>  FIXTURE_VARIANT_ADD(basic, vdso) {
>  	.name = "[vdso]",
> -	.sealed = true,
> +	.sysmap = true,
>  };
>
>  FIXTURE_VARIANT_ADD(basic, vvar) {
>  	.name = "[vvar]",
> -	.sealed = true,
> +	.sysmap = true,
>  };
>
>  FIXTURE_VARIANT_ADD(basic, vvar_vclock) {
>  	.name = "[vvar_vclock]",
> -	.sealed = true,
> +	.sysmap = true,
>  };
>
>  FIXTURE_VARIANT_ADD(basic, sigpage) {
>  	.name = "[sigpage]",
> -	.sealed = true,
> +	.sysmap = true,
>  };
>
>  FIXTURE_VARIANT_ADD(basic, vectors) {
>  	.name = "[vectors]",
> -	.sealed = true,
> +	.sysmap = true,
>  };
>
>  FIXTURE_VARIANT_ADD(basic, uprobes) {
>  	.name = "[uprobes]",
> -	.sealed = true,
> +	.sysmap = true,
>  };
>
>  FIXTURE_VARIANT_ADD(basic, stack) {
>  	.name = "[stack]",
> -	.sealed = false,
> +	.sysmap = false,
>  };
>
>  TEST_F(basic, check_sealed)
>  {
> +	int expected = 0, sealed;
> +
>  	if (!has_mapping(variant->name, self->maps)) {
>  		SKIP(return, "could not find the mapping, %s",
>  			variant->name);
>  	}
>
> -	EXPECT_EQ(variant->sealed,
> -		mapping_is_sealed(variant->name, self->maps));
> +	sealed = mapping_is_sealed(self->maps);
> +	if (sealed < 0)
> +		SKIP(return, "could not read the mapping's sealing state");
> +	if (variant->sysmap) {
> +		expected = sysmap_sealed_expected();
> +		if (expected < 0)
> +			SKIP(return, "could not determine the expected sealing state");
> +	}
> +	EXPECT_EQ(expected, sealed);
>  };
>
>  TEST_HARNESS_MAIN
> --
> 2.54.0
>

--
Cheers, Lorenzo

Re: [PATCH 1/3] mseal sysmap: Add mseal_system_mappings= boot parameter

[Chris Down]

Hi Lorenzo,

Thanks for the quick and thorough review!

Lorenzo Stoakes (ARM) writes:
>The existing implementation is a bit of a mess, so any work that extends it
>has to put in the work to improve things first.
>
>I _hate_ VM_SEALED_SYSMAP. It's a hack. A tasteful way of doing this is
>really required for a series touching this to be taken, honestly.
>
>See below for implementation ideas.

That's fair, I'll do the cleanup first in v2.

>(Also it's the merge window, so no more revisions until -rc1, when you need
>to resend, thanks.)

Sure, I'll wait until after -rc1.

>Could we have some actual justification for the use of the feature please?
>So far I've seen arm-waving.

Sure. At Meta, we build sealing into the kernel for our VM hosts, and we'd like 
it on as much of the rest of the fleet as possible. The problem is that the 
rest of the fleet also runs things which it breaks. Just as one example among 
many, Reverie (which Hermit our deterministic execution tool is built on) 
patches the vDSO of the processes it traces by injecting an mprotect()[0].

So right now the hosts which want sealing need their own kernel image, and this 
option is one of the things which forces that. We're working towards hopefully 
running one kernel across the fleet, and with a boot parameter we can build it 
with CONFIG_MSEAL_SYSTEM_MAPPINGS=y, keep sealing on by default, and turn it 
off only on the hosts which run those tools.

Let me know if you'd like more information. I can also put that in the commit 
message for v2.

0: https://docs.rs/reverie-core/latest/reverie/vdso/index.html

>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>> index e75344f4e0cd..b1ec9a8a979e 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -4270,6 +4270,13 @@ Kernel parameters
>>  	MTD_Region=	[MTD] Format:
>>  			<name>,<region-number>[,<base>,<size>,<buswidth>,<altbuswidth>]
>>
>> +	mseal_system_mappings=
>> +			[KNL,EARLY] Under CONFIG_MSEAL_SYSTEM_MAPPINGS,
>> +			whether system mappings are sealed for this boot.
>> +			See Documentation/userspace-api/mseal.rst.
>> +			Format: <bool>
>> +			Default: 1 (enabled).
>
>You _have_ to duplicate the list of things this breaks here please.

Will do.

>Let's negate things first. Make the boot flag 'no_mseal_sys_mappings'
>rather than confusingly implying mseal_system_mappings=1 could enable it
>even with a config option not provided.
>
>Then add something like:
>
>static inline bool mseal_system_mappings(void)
>{
>        return IS_ENABLED(CONFIG_MSEAL_SYSTEM_MAPPINGS) &&
>               !mseal_system_mappings_disabled;
>}
>
>And call that in _install_special_mapping().

Makes sense. I'll call it in __install_special_mapping(), since that's where we 
already have a vma_flags_t, so it can just set VMA_SEALED_BIT without going 
near the legacy flags at all, if that sounds good? Then VM_SEALED_SYSMAP and 
all of its users can hopefully go away.

>The LLM overlords tell me that only uprobe trampolines would see a delta
>from this given the ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS restriction.
>
>This would improve things a lot.

Yes, but there is a wrinkle. Since 07c308eb2bcf ("uprobes/x86: Do not leak 
trampoline vma mapping on optimization failure"), __arch_uprobe_optimize() 
unmaps a trampoline it has just created if swbp_optimize() fails, and with the 
trampoline sealed that would now fail with -EPERM. I can see two ways to deal 
with that:

One is to seal trampolines too, and just leave a sealed trampoline in place on 
that path. It's already a WARN_ON_ONCE(), and get_uprobe_trampoline() reuses 
any trampoline which is in reach, so nothing is really leaked.

Another way would be to keep trampolines unsealed, but that means bringing back 
some kind of per-mapping opt-in, which is exactly what we're trying to get rid 
of.

What do you think? Either way I'll Cc Jiri and Oleg on it.

>> +#define VM_SEALED_SYSMAP	(mseal_sysmap_enabled ? VM_SEALED : VM_NONE)
>
>No, you don't use the legacy VMA flags API for new work. Sorry.
>
>See above as to a pointer as to how this should look.

Sure thing.

>>  static bool range_contains_unmapped(unsigned long start, unsigned long end)
>>  {
>>  	VMA_ITERATOR(vmi, current->mm, start);
>> diff --git a/security/Kconfig b/security/Kconfig
>> index f7bf6cdc6229..d5e83af1bfc6 100644
>> --- a/security/Kconfig
>> +++ b/security/Kconfig
>> @@ -67,6 +67,8 @@ config MSEAL_SYSTEM_MAPPINGS
>>  	  of writing includes CHECKPOINT_RESTORE, UML, gVisor, rr. Therefore
>>  	  this config can't be enabled universally.
>>
>> +	  Sealing can be turned off at boot with "mseal_system_mappings=0".
>> +
>
>'With this configuration option set, sealing can...' right now this reads a
>little like it's defaulted on.
>
>Also can we move this Kconfig option out of security and into mm please?
>This is explicitly an mm feature, and it should never have been added there
>(mm needs to know if somebody sets this default=y or something for
>instance).

Sure thing.

>Tests as separate commits please.

Happy to do so, but aren't you worried about bisect safety? Or would you 
suggest another way?

>This seems total overkill, you're checking whether a boot parameter works?

It was mostly there so that the existing test wouldn't fail when booted with 
mseal_system_mappings=0, which meant parsing a bool. With a negated flag it can 
be a lot simpler, but I'm not sure which of these you'd prefer:

One option is to skip if [vdso] isn't sealed, and otherwise expect all system 
mappings to be sealed. Then there's parsing at all, and it also stops failing 
on kernels built without CONFIG_MSEAL_SYSTEM_MAPPINGS, which matters more once 
it's in run_vmtests.sh. The downside is that it can't notice sealing being 
broken entirely.

Another is to check /proc/cmdline for no_mseal_sys_mappings and expect the 
mappings to be unsealed if it's there. That's only a few lines now, but the 
test still fails on kernels without the option, as it does today.

Do you have a preference between the two?

Thanks a lot for the review!

Re: [PATCH 1/3] mseal sysmap: Add mseal_system_mappings= boot parameter

[Lorenzo Stoakes (ARM)]

On Wed, Oct 28, 2026 at 12:37:05AM +0800, Chris Down wrote:
> Hi Lorenzo,
>
> Thanks for the quick and thorough review!

No worries!

>
> Lorenzo Stoakes (ARM) writes:
> > The existing implementation is a bit of a mess, so any work that extends it
> > has to put in the work to improve things first.
> >
> > I _hate_ VM_SEALED_SYSMAP. It's a hack. A tasteful way of doing this is
> > really required for a series touching this to be taken, honestly.
> >
> > See below for implementation ideas.
>
> That's fair, I'll do the cleanup first in v2.

Thanks!

>
> > (Also it's the merge window, so no more revisions until -rc1, when you need
> > to resend, thanks.)
>
> Sure, I'll wait until after -rc1.

Yup :) we are a bit inundated with AI fixes these days.

>
> > Could we have some actual justification for the use of the feature please?
> > So far I've seen arm-waving.
>
> Sure. At Meta, we build sealing into the kernel for our VM hosts, and we'd
> like it on as much of the rest of the fleet as possible. The problem is that
> the rest of the fleet also runs things which it breaks. Just as one example
> among many, Reverie (which Hermit our deterministic execution tool is built
> on) patches the vDSO of the processes it traces by injecting an
> mprotect()[0].
>
> So right now the hosts which want sealing need their own kernel image, and
> this option is one of the things which forces that. We're working towards
> hopefully running one kernel across the fleet, and with a boot parameter we
> can build it with CONFIG_MSEAL_SYSTEM_MAPPINGS=y, keep sealing on by
> default, and turn it off only on the hosts which run those tools.
>
> Let me know if you'd like more information. I can also put that in the
> commit message for v2.

Great, thanks for the background! Yeah it'd be good to include all that!

I guess I'm fishing for the security justification, but maybe that ship sailed
:) but it'd be helpful to also include that.

>
> 0: https://docs.rs/reverie-core/latest/reverie/vdso/index.html
>
> > > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> > > index e75344f4e0cd..b1ec9a8a979e 100644
> > > --- a/Documentation/admin-guide/kernel-parameters.txt
> > > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > > @@ -4270,6 +4270,13 @@ Kernel parameters
> > >  	MTD_Region=	[MTD] Format:
> > >  			<name>,<region-number>[,<base>,<size>,<buswidth>,<altbuswidth>]
> > >
> > > +	mseal_system_mappings=
> > > +			[KNL,EARLY] Under CONFIG_MSEAL_SYSTEM_MAPPINGS,
> > > +			whether system mappings are sealed for this boot.
> > > +			See Documentation/userspace-api/mseal.rst.
> > > +			Format: <bool>
> > > +			Default: 1 (enabled).
> >
> > You _have_ to duplicate the list of things this breaks here please.
>
> Will do.

Thanks!

>
> > Let's negate things first. Make the boot flag 'no_mseal_sys_mappings'
> > rather than confusingly implying mseal_system_mappings=1 could enable it
> > even with a config option not provided.
> >
> > Then add something like:
> >
> > static inline bool mseal_system_mappings(void)
> > {
> >        return IS_ENABLED(CONFIG_MSEAL_SYSTEM_MAPPINGS) &&
> >               !mseal_system_mappings_disabled;
> > }
> >
> > And call that in _install_special_mapping().
>
> Makes sense. I'll call it in __install_special_mapping(), since that's where
> we already have a vma_flags_t, so it can just set VMA_SEALED_BIT without
> going near the legacy flags at all, if that sounds good? Then
> VM_SEALED_SYSMAP and all of its users can hopefully go away.

Yeah I typo'd that haha, doh! And it just happens to be a function :) yes
__install_special_mapping().

>
> > The LLM overlords tell me that only uprobe trampolines would see a delta
> > from this given the ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS restriction.
> >
> > This would improve things a lot.
>
> Yes, but there is a wrinkle. Since 07c308eb2bcf ("uprobes/x86: Do not leak
> trampoline vma mapping on optimization failure"), __arch_uprobe_optimize()
> unmaps a trampoline it has just created if swbp_optimize() fails, and with
> the trampoline sealed that would now fail with -EPERM. I can see two ways to
> deal with that:
>
> One is to seal trampolines too, and just leave a sealed trampoline in place
> on that path. It's already a WARN_ON_ONCE(), and get_uprobe_trampoline()
> reuses any trampoline which is in reach, so nothing is really leaked.
>
> Another way would be to keep trampolines unsealed, but that means bringing
> back some kind of per-mapping opt-in, which is exactly what we're trying to
> get rid of.
>
> What do you think? Either way I'll Cc Jiri and Oleg on it.

I think the easiest would be to just seal them too.

>
> > > +#define VM_SEALED_SYSMAP	(mseal_sysmap_enabled ? VM_SEALED : VM_NONE)
> >
> > No, you don't use the legacy VMA flags API for new work. Sorry.
> >
> > See above as to a pointer as to how this should look.
>
> Sure thing.

Thanks, but with the proposed alternative approach, we can just yeet this from
the code anyway! :)

>
> > >  static bool range_contains_unmapped(unsigned long start, unsigned long end)
> > >  {
> > >  	VMA_ITERATOR(vmi, current->mm, start);
> > > diff --git a/security/Kconfig b/security/Kconfig
> > > index f7bf6cdc6229..d5e83af1bfc6 100644
> > > --- a/security/Kconfig
> > > +++ b/security/Kconfig
> > > @@ -67,6 +67,8 @@ config MSEAL_SYSTEM_MAPPINGS
> > >  	  of writing includes CHECKPOINT_RESTORE, UML, gVisor, rr. Therefore
> > >  	  this config can't be enabled universally.
> > >
> > > +	  Sealing can be turned off at boot with "mseal_system_mappings=0".
> > > +
> >
> > 'With this configuration option set, sealing can...' right now this reads a
> > little like it's defaulted on.
> >
> > Also can we move this Kconfig option out of security and into mm please?
> > This is explicitly an mm feature, and it should never have been added there
> > (mm needs to know if somebody sets this default=y or something for
> > instance).
>
> Sure thing.

Thank!

>
> > Tests as separate commits please.
>
> Happy to do so, but aren't you worried about bisect safety? Or would you
> suggest another way?
>
> > This seems total overkill, you're checking whether a boot parameter works?
>
> It was mostly there so that the existing test wouldn't fail when booted with
> mseal_system_mappings=0, which meant parsing a bool. With a negated flag it
> can be a lot simpler, but I'm not sure which of these you'd prefer:
>
> One option is to skip if [vdso] isn't sealed, and otherwise expect all
> system mappings to be sealed. Then there's parsing at all, and it also stops
> failing on kernels built without CONFIG_MSEAL_SYSTEM_MAPPINGS, which matters
> more once it's in run_vmtests.sh. The downside is that it can't notice
> sealing being broken entirely.
>
> Another is to check /proc/cmdline for no_mseal_sys_mappings and expect the
> mappings to be unsealed if it's there. That's only a few lines now, but the
> test still fails on kernels without the option, as it does today.
>
> Do you have a preference between the two?
>

Yeah it's awkward, really moving the tests to mm we'd have to skip them if the
vdso isn't sealed, then assume a sealed vdso for a new process = feature
enabled.

I guess at that point it's redundant to check if disabled?

> Thanks a lot for the review!

No worries!

--
Cheers, Lorenzo

[PATCH 2/3] mseal sysmap: Allow with CHECKPOINT_RESTORE, default off

[Chris Down]

MSEAL_SYSTEM_MAPPINGS depends on !CHECKPOINT_RESTORE because CRIU moves
system mappings when restoring a process. Now that sealing can be chosen
at boot we should instead use this to determine defaults.

Let's add MSEAL_SYSTEM_MAPPINGS_DEFAULT_ON and move the dependency
there. Existing configurations retain their behaviour. Kernels built
with CHECKPOINT_RESTORE can build sealing in, but will only seal
mappings when explicitly requested with mseal_system_mappings=1.

Hosts can also share a kernel built with MSEAL_SYSTEM_MAPPINGS=y and
MSEAL_SYSTEM_MAPPINGS_DEFAULT_ON=n, enabling sealing only where needed.
This lets hosts which need sealing share the kernel image with hosts
which need their system mappings to remain movable, which simplifies
deployment.

Signed-off-by: Chris Down <chris@chrisdown.name>
---
 .../admin-guide/kernel-parameters.txt         |  2 +-
 Documentation/userspace-api/mseal.rst         |  4 +-
 mm/mseal.c                                    |  3 +-
 security/Kconfig                              | 17 +++++++-
 .../selftests/mseal_system_mappings/Makefile  |  2 +
 .../selftests/mseal_system_mappings/config    |  2 +
 .../mseal_system_mappings/sysmap_is_sealed.c  | 42 ++++++++++++++++++-
 7 files changed, 66 insertions(+), 6 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index b1ec9a8a979e..628f4cccd38e 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -4275,7 +4275,7 @@ Kernel parameters
 			whether system mappings are sealed for this boot.
 			See Documentation/userspace-api/mseal.rst.
 			Format: <bool>
-			Default: 1 (enabled).
+			Default set by CONFIG_MSEAL_SYSTEM_MAPPINGS_DEFAULT_ON.
 
 	mtdparts=	[MTD]
 			See drivers/mtd/parsers/cmdlinepart.c
diff --git a/Documentation/userspace-api/mseal.rst b/Documentation/userspace-api/mseal.rst
index 4e50215e4762..c1d6dbb006dc 100644
--- a/Documentation/userspace-api/mseal.rst
+++ b/Documentation/userspace-api/mseal.rst
@@ -143,7 +143,9 @@ Use cases
   If supported by an architecture (CONFIG_ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS),
   the CONFIG_MSEAL_SYSTEM_MAPPINGS seals all system mappings of this
   architecture. The kernel command line parameter
-  ``mseal_system_mappings=0`` turns this off at boot.
+  ``mseal_system_mappings=0|1`` turns this off or on at boot. The default is
+  set by CONFIG_MSEAL_SYSTEM_MAPPINGS_DEFAULT_ON, which is off with
+  CONFIG_CHECKPOINT_RESTORE.
 
   WARNING: This feature breaks programs which rely on relocating
   or unmapping system mappings. Known broken software at the time
diff --git a/mm/mseal.c b/mm/mseal.c
index e0563796cfa3..8f2f2a149915 100644
--- a/mm/mseal.c
+++ b/mm/mseal.c
@@ -19,7 +19,8 @@
 #include "internal.h"
 
 #ifdef CONFIG_MSEAL_SYSTEM_MAPPINGS
-bool mseal_sysmap_enabled __ro_after_init = true;
+bool mseal_sysmap_enabled __ro_after_init =
+	IS_ENABLED(CONFIG_MSEAL_SYSTEM_MAPPINGS_DEFAULT_ON);
 
 static int __init early_mseal_sysmap(char *buf)
 {
diff --git a/security/Kconfig b/security/Kconfig
index d5e83af1bfc6..6a6323e0897d 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -53,7 +53,6 @@ config MSEAL_SYSTEM_MAPPINGS
 	bool "mseal system mappings"
 	depends on 64BIT
 	depends on ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS
-	depends on !CHECKPOINT_RESTORE
 	help
 	  Apply mseal on system mappings.
 	  The system mappings includes vdso, vvar, vvar_vclock,
@@ -67,11 +66,25 @@ config MSEAL_SYSTEM_MAPPINGS
 	  of writing includes CHECKPOINT_RESTORE, UML, gVisor, rr. Therefore
 	  this config can't be enabled universally.
 
-	  Sealing can be turned off at boot with "mseal_system_mappings=0".
+	  The "mseal_system_mappings=" kernel command line parameter can
+	  be used to enable or disable sealing at boot. The default is set
+	  by MSEAL_SYSTEM_MAPPINGS_DEFAULT_ON.
 
 	  For complete descriptions of memory sealing, please see
 	  Documentation/userspace-api/mseal.rst
 
+config MSEAL_SYSTEM_MAPPINGS_DEFAULT_ON
+	bool "Seal system mappings by default"
+	depends on MSEAL_SYSTEM_MAPPINGS
+	depends on !CHECKPOINT_RESTORE
+	default y
+	help
+	  Sets the default for the "mseal_system_mappings=" boot parameter.
+
+	  With CHECKPOINT_RESTORE=y, system mappings are only sealed when
+	  "mseal_system_mappings=1" is given, since CRIU needs to move them
+	  when restoring a process.
+
 config SECURITY
 	bool "Enable different security models"
 	depends on SYSFS
diff --git a/tools/testing/selftests/mseal_system_mappings/Makefile b/tools/testing/selftests/mseal_system_mappings/Makefile
index 2b4504e2f52f..d3b88af06c94 100644
--- a/tools/testing/selftests/mseal_system_mappings/Makefile
+++ b/tools/testing/selftests/mseal_system_mappings/Makefile
@@ -1,6 +1,8 @@
 # SPDX-License-Identifier: GPL-2.0-only
 CFLAGS += -std=c99 -pthread -Wall $(KHDR_INCLUDES)
 
+LDLIBS += -lz
+
 TEST_GEN_PROGS := sysmap_is_sealed
 
 include ../lib.mk
diff --git a/tools/testing/selftests/mseal_system_mappings/config b/tools/testing/selftests/mseal_system_mappings/config
index 675cb9f37b86..493bbf834a84 100644
--- a/tools/testing/selftests/mseal_system_mappings/config
+++ b/tools/testing/selftests/mseal_system_mappings/config
@@ -1 +1,3 @@
 CONFIG_MSEAL_SYSTEM_MAPPINGS=y
+CONFIG_IKCONFIG=y
+CONFIG_IKCONFIG_PROC=y
diff --git a/tools/testing/selftests/mseal_system_mappings/sysmap_is_sealed.c b/tools/testing/selftests/mseal_system_mappings/sysmap_is_sealed.c
index 97348c2a0689..ea75ad537620 100644
--- a/tools/testing/selftests/mseal_system_mappings/sysmap_is_sealed.c
+++ b/tools/testing/selftests/mseal_system_mappings/sysmap_is_sealed.c
@@ -10,6 +10,8 @@
 #include <unistd.h>
 #include <string.h>
 #include <stdbool.h>
+#include <sys/utsname.h>
+#include <zlib.h>
 
 #include "kselftest.h"
 #include "kselftest_harness.h"
@@ -52,14 +54,52 @@ static int parse_bool(const char *s, bool *res)
 	return -EINVAL;
 }
 
+static int sysmap_config_expected(int *enabled)
+{
+	struct utsname uts;
+	char line[MAX_LINE_LEN];
+	bool default_on = false;
+	gzFile config;
+	int expected;
+
+	*enabled = -1;
+	config = gzopen("/proc/config.gz", "rb");
+	if (!config && !uname(&uts)) {
+		snprintf(line, sizeof(line), "/boot/config-%s", uts.release);
+		config = gzopen(line, "rb");
+	}
+	if (!config)
+		return -1;
+
+	while (gzgets(config, line, sizeof(line))) {
+		if (!strcmp(line, "CONFIG_MSEAL_SYSTEM_MAPPINGS=y\n"))
+			*enabled = 1;
+		else if (!strcmp(line,
+				 "# CONFIG_MSEAL_SYSTEM_MAPPINGS is not set\n"))
+			*enabled = 0;
+		else if (!strcmp(line,
+				 "CONFIG_MSEAL_SYSTEM_MAPPINGS_DEFAULT_ON=y\n"))
+			default_on = true;
+	}
+	if (!gzeof(config))
+		*enabled = -1;
+	expected = *enabled < 0 ? -1 : *enabled && default_on;
+	gzclose(config);
+	return expected;
+}
+
 static int sysmap_sealed_expected(void)
 {
 	char cmdline[4096], *tok, *save;
-	int sealed = 1;
+	int enabled, sealed;
 	bool value;
 	size_t len;
 	FILE *f;
 
+	sealed = sysmap_config_expected(&enabled);
+	if (!enabled)
+		return 0;
+
 	f = fopen("/proc/cmdline", "r");
 	if (!f)
 		return -1;
-- 
2.54.0

Re: [PATCH 2/3] mseal sysmap: Allow with CHECKPOINT_RESTORE, default off

[Lorenzo Stoakes (ARM)]

On Tue, Oct 27, 2026 at 07:43:17PM +0800, Chris Down wrote:
> MSEAL_SYSTEM_MAPPINGS depends on !CHECKPOINT_RESTORE because CRIU moves
> system mappings when restoring a process. Now that sealing can be chosen
> at boot we should instead use this to determine defaults.
>
> Let's add MSEAL_SYSTEM_MAPPINGS_DEFAULT_ON and move the dependency
> there. Existing configurations retain their behaviour. Kernels built
> with CHECKPOINT_RESTORE can build sealing in, but will only seal
> mappings when explicitly requested with mseal_system_mappings=1.
>
> Hosts can also share a kernel built with MSEAL_SYSTEM_MAPPINGS=y and
> MSEAL_SYSTEM_MAPPINGS_DEFAULT_ON=n, enabling sealing only where needed.
> This lets hosts which need sealing share the kernel image with hosts
> which need their system mappings to remain movable, which simplifies
> deployment.
>
> Signed-off-by: Chris Down <chris@chrisdown.name>

Sorry, NAK to this patch. It's adding far too much complexity.

The honest version of this is removing the CRIU dependency, and since it's well
documented that many things break if you use it, and the config option is
default-no, then it's kinda your own fault if you insist on doing the broken
thing.

So I don't think I'd mind that, and it'd make the change simpler, as you could
fold it into patch 1 also ;)

--
Cheers, Lorenzo

Re: [PATCH 2/3] mseal sysmap: Allow with CHECKPOINT_RESTORE, default off

[Chris Down]

Ok, sounds good. I'll drop MSEAL_SYSTEM_MAPPINGS_DEFAULT_ON, and fold dropping 
the !CHECKPOINT_RESTORE dependency into the boot parameter patch. Thanks!

Re: [PATCH 2/3] mseal sysmap: Allow with CHECKPOINT_RESTORE, default off

[Lorenzo Stoakes (ARM)]

On Wed, Oct 28, 2026 at 12:37:41AM +0800, Chris Down wrote:
> Ok, sounds good. I'll drop MSEAL_SYSTEM_MAPPINGS_DEFAULT_ON, and fold
> dropping the !CHECKPOINT_RESTORE dependency into the boot parameter patch.
> Thanks!

Thanks!

--
Cheers, Lorenzo

[PATCH 3/3] selftests/mseal_system_mappings: Test vdso unmap and remap

[Chris Down]

Signed-off-by: Chris Down <chris@chrisdown.name>
---
 .../mseal_system_mappings/sysmap_is_sealed.c  | 92 +++++++++++++++++++
 1 file changed, 92 insertions(+)

diff --git a/tools/testing/selftests/mseal_system_mappings/sysmap_is_sealed.c b/tools/testing/selftests/mseal_system_mappings/sysmap_is_sealed.c
index ea75ad537620..83b4fadfbfe7 100644
--- a/tools/testing/selftests/mseal_system_mappings/sysmap_is_sealed.c
+++ b/tools/testing/selftests/mseal_system_mappings/sysmap_is_sealed.c
@@ -10,6 +10,7 @@
 #include <unistd.h>
 #include <string.h>
 #include <stdbool.h>
+#include <sys/mman.h>
 #include <sys/utsname.h>
 #include <zlib.h>
 
@@ -232,4 +233,95 @@ TEST_F(basic, check_sealed)
 	EXPECT_EQ(expected, sealed);
 };
 
+static bool find_vdso(unsigned long *start, unsigned long *end)
+{
+	char line[MAX_LINE_LEN];
+	bool found = false;
+	FILE *maps;
+
+	maps = fopen("/proc/self/maps", "r");
+	if (!maps)
+		return false;
+
+	while (fgets(line, sizeof(line), maps)) {
+		if (strstr(line, "[vdso]") &&
+		    sscanf(line, "%lx-%lx", start, end) == 2) {
+			found = true;
+			break;
+		}
+	}
+
+	fclose(maps);
+	return found;
+}
+
+static int vdso_is_sealed(void)
+{
+	int sealed = -1;
+	FILE *maps;
+
+	maps = fopen("/proc/self/smaps", "r");
+	if (!maps)
+		return -1;
+	if (has_mapping("[vdso]", maps))
+		sealed = mapping_is_sealed(maps);
+	fclose(maps);
+	return sealed;
+}
+
+/*
+ * Unmapping or moving [vdso] must fail with EPERM when it is sealed. When it
+ * is not sealed, it succeeds and leaves glibc with a stale vdso pointer, which
+ * is fine because each test runs in its own forked child.
+ */
+TEST(vdso_munmap)
+{
+	int sealed;
+	unsigned long start, end;
+	int ret;
+
+	if (!find_vdso(&start, &end))
+		SKIP(return, "could not find the mapping, [vdso]");
+	sealed = vdso_is_sealed();
+	if (sealed < 0)
+		SKIP(return, "could not read the [vdso] sealing state");
+
+	ret = munmap((void *)start, end - start);
+	if (sealed) {
+		EXPECT_EQ(-1, ret);
+		EXPECT_EQ(EPERM, errno);
+	} else {
+		EXPECT_EQ(0, ret);
+	}
+	EXPECT_EQ(sealed, find_vdso(&start, &end));
+}
+
+TEST(vdso_mremap)
+{
+	int sealed;
+	unsigned long start, end, size, new_start;
+	void *dst, *ret;
+
+	if (!find_vdso(&start, &end))
+		SKIP(return, "could not find the mapping, [vdso]");
+	sealed = vdso_is_sealed();
+	if (sealed < 0)
+		SKIP(return, "could not read the [vdso] sealing state");
+	size = end - start;
+
+	dst = mmap(NULL, size, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+	ASSERT_NE(MAP_FAILED, dst);
+
+	ret = mremap((void *)start, size, size, MREMAP_MAYMOVE | MREMAP_FIXED,
+		     dst);
+	if (sealed) {
+		EXPECT_EQ(MAP_FAILED, ret);
+		EXPECT_EQ(EPERM, errno);
+	} else {
+		EXPECT_EQ(dst, ret);
+	}
+	ASSERT_TRUE(find_vdso(&new_start, &end));
+	EXPECT_EQ(sealed ? start : (unsigned long)dst, new_start);
+}
+
 TEST_HARNESS_MAIN
-- 
2.54.0

Re: [PATCH 3/3] selftests/mseal_system_mappings: Test vdso unmap and remap

[Lorenzo Stoakes (ARM)]

Sorry, in mm we require commit messages. Even for tests :)

On Tue, Oct 27, 2026 at 07:43:25PM +0800, Chris Down wrote:
> Signed-off-by: Chris Down <chris@chrisdown.name>
> ---
>  .../mseal_system_mappings/sysmap_is_sealed.c  | 92 +++++++++++++++++++
>  1 file changed, 92 insertions(+)
>
> diff --git a/tools/testing/selftests/mseal_system_mappings/sysmap_is_sealed.c b/tools/testing/selftests/mseal_system_mappings/sysmap_is_sealed.c
> index ea75ad537620..83b4fadfbfe7 100644
> --- a/tools/testing/selftests/mseal_system_mappings/sysmap_is_sealed.c
> +++ b/tools/testing/selftests/mseal_system_mappings/sysmap_is_sealed.c

Why on earth does 'mseal_system_mappings' have its own directory...??

Ugh I don't know how I let this stuff go on the original series :/

Please, for the love of all that's sacred, move these tests over to
tools/selftests/mm/. This is an mm feature, for our sins...

You can do the move as a prerequisite patch in the series.

(And, again, I really do insist on your change doing some cleanup here as
 well rather than extending this stuff.)

> @@ -10,6 +10,7 @@
>  #include <unistd.h>
>  #include <string.h>
>  #include <stdbool.h>
> +#include <sys/mman.h>
>  #include <sys/utsname.h>
>  #include <zlib.h>
>
> @@ -232,4 +233,95 @@ TEST_F(basic, check_sealed)
>  	EXPECT_EQ(expected, sealed);
>  };
>
> +static bool find_vdso(unsigned long *start, unsigned long *end)
> +{
> +	char line[MAX_LINE_LEN];
> +	bool found = false;
> +	FILE *maps;
> +
> +	maps = fopen("/proc/self/maps", "r");
> +	if (!maps)
> +		return false;
> +
> +	while (fgets(line, sizeof(line), maps)) {
> +		if (strstr(line, "[vdso]") &&
> +		    sscanf(line, "%lx-%lx", start, end) == 2) {
> +			found = true;
> +			break;
> +		}
> +	}
> +
> +	fclose(maps);
> +	return found;
> +}

There's shared code for this kind of thing, please don't duplicate a
/proc/self/maps thing if unnecessary. Also there's a nicer ioctl interface for
all this.

See vm_utils.[ch].

> +
> +static int vdso_is_sealed(void)
> +{
> +	int sealed = -1;
> +	FILE *maps;
> +
> +	maps = fopen("/proc/self/smaps", "r");
> +	if (!maps)
> +		return -1;
> +	if (has_mapping("[vdso]", maps))
> +		sealed = mapping_is_sealed(maps);
> +	fclose(maps);
> +	return sealed;
> +}
> +
> +/*
> + * Unmapping or moving [vdso] must fail with EPERM when it is sealed. When it
> + * is not sealed, it succeeds and leaves glibc with a stale vdso pointer, which
> + * is fine because each test runs in its own forked child.
> + */
> +TEST(vdso_munmap)
> +{
> +	int sealed;
> +	unsigned long start, end;
> +	int ret;
> +
> +	if (!find_vdso(&start, &end))
> +		SKIP(return, "could not find the mapping, [vdso]");
> +	sealed = vdso_is_sealed();
> +	if (sealed < 0)
> +		SKIP(return, "could not read the [vdso] sealing state");
> +
> +	ret = munmap((void *)start, end - start);
> +	if (sealed) {
> +		EXPECT_EQ(-1, ret);
> +		EXPECT_EQ(EPERM, errno);
> +	} else {
> +		EXPECT_EQ(0, ret);
> +	}
> +	EXPECT_EQ(sealed, find_vdso(&start, &end));
> +}
> +
> +TEST(vdso_mremap)
> +{
> +	int sealed;
> +	unsigned long start, end, size, new_start;
> +	void *dst, *ret;
> +
> +	if (!find_vdso(&start, &end))
> +		SKIP(return, "could not find the mapping, [vdso]");
> +	sealed = vdso_is_sealed();
> +	if (sealed < 0)
> +		SKIP(return, "could not read the [vdso] sealing state");
> +	size = end - start;
> +
> +	dst = mmap(NULL, size, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
> +	ASSERT_NE(MAP_FAILED, dst);
> +
> +	ret = mremap((void *)start, size, size, MREMAP_MAYMOVE | MREMAP_FIXED,
> +		     dst);

I mean arguably this is an mremap test that belongs with mremap? I guess
debatable...

> +	if (sealed) {
> +		EXPECT_EQ(MAP_FAILED, ret);
> +		EXPECT_EQ(EPERM, errno);
> +	} else {
> +		EXPECT_EQ(dst, ret);
> +	}
> +	ASSERT_TRUE(find_vdso(&new_start, &end));
> +	EXPECT_EQ(sealed ? start : (unsigned long)dst, new_start);
> +}
> +
>  TEST_HARNESS_MAIN
> --
> 2.54.0
>

This all just seems like work that should have been done in the past when this
feature was proposed, and doesn't depend on your changes at all AFAICT? Maybe I
missed it though.

Valuable in itself, but probably worth sending separately as a result? Otherwise
it's a little disconnected from the actual change you're making.

--
Cheers, Lorenzo

Re: [PATCH 3/3] selftests/mseal_system_mappings: Test vdso unmap and remap

[Chris Down]

Lorenzo Stoakes (ARM) writes:
>Sorry, in mm we require commit messages. Even for tests :)

Sure thing, I'll add one.

>On Tue, Oct 27, 2026 at 07:43:25PM +0800, Chris Down wrote:
>> Signed-off-by: Chris Down <chris@chrisdown.name>
>> ---
>>  .../mseal_system_mappings/sysmap_is_sealed.c  | 92 +++++++++++++++++++
>>  1 file changed, 92 insertions(+)
>>
>> diff --git a/tools/testing/selftests/mseal_system_mappings/sysmap_is_sealed.c b/tools/testing/selftests/mseal_system_mappings/sysmap_is_sealed.c
>> index ea75ad537620..83b4fadfbfe7 100644
>> --- a/tools/testing/selftests/mseal_system_mappings/sysmap_is_sealed.c
>> +++ b/tools/testing/selftests/mseal_system_mappings/sysmap_is_sealed.c
>
>Why on earth does 'mseal_system_mappings' have its own directory...??
>
>Ugh I don't know how I let this stuff go on the original series :/
>
>Please, for the love of all that's sacred, move these tests over to
>tools/selftests/mm/. This is an mm feature, for our sins...
>
>You can do the move as a prerequisite patch in the series.

Will do, I'll make the move the first patch.

>(And, again, I really do insist on your change doing some cleanup here as
> well rather than extending this stuff.)

Yep, see my reply to 1/3.

>> @@ -10,6 +10,7 @@
>>  #include <unistd.h>
>>  #include <string.h>
>>  #include <stdbool.h>
>> +#include <sys/mman.h>
>>  #include <sys/utsname.h>
>>  #include <zlib.h>
>>
>> @@ -232,4 +233,95 @@ TEST_F(basic, check_sealed)
>>  	EXPECT_EQ(expected, sealed);
>>  };
>>
>> +static bool find_vdso(unsigned long *start, unsigned long *end)
>> +{
>> +	char line[MAX_LINE_LEN];
>> +	bool found = false;
>> +	FILE *maps;
>> +
>> +	maps = fopen("/proc/self/maps", "r");
>> +	if (!maps)
>> +		return false;
>> +
>> +	while (fgets(line, sizeof(line), maps)) {
>> +		if (strstr(line, "[vdso]") &&
>> +		    sscanf(line, "%lx-%lx", start, end) == 2) {
>> +			found = true;
>> +			break;
>> +		}
>> +	}
>> +
>> +	fclose(maps);
>> +	return found;
>> +}
>
>There's shared code for this kind of thing, please don't duplicate a
>/proc/self/maps thing if unnecessary. Also there's a nicer ioctl interface for
>all this.
>
>See vm_utils.[ch].

Oh thank you! I will use that.

>I mean arguably this is an mremap test that belongs with mremap? I guess
>debatable...

Hmm, I'd lean towards keeping it with the sysmap test, since it's really 
testing that the seal is enforced on these mappings rather than anything about 
mremap() itself, but I don't feel strongly if you insist, just let me know.

>This all just seems like work that should have been done in the past when this
>feature was proposed, and doesn't depend on your changes at all AFAICT? Maybe I
>missed it though.
>
>Valuable in itself, but probably worth sending separately as a result? Otherwise
>it's a little disconnected from the actual change you're making.

Yeah, it doesn't depend on it. I can send it separately on top of the move if 
you like, I just don't like touching things without tests where possible.

Thanks for the review!

Re: [PATCH 3/3] selftests/mseal_system_mappings: Test vdso unmap and remap

[Lorenzo Stoakes (ARM)]

On Wed, Oct 28, 2026 at 12:40:32AM +0800, Chris Down wrote:
> Lorenzo Stoakes (ARM) writes:
> > Sorry, in mm we require commit messages. Even for tests :)
>
> Sure thing, I'll add one.
>
> > On Tue, Oct 27, 2026 at 07:43:25PM +0800, Chris Down wrote:
> > > Signed-off-by: Chris Down <chris@chrisdown.name>
> > > ---
> > >  .../mseal_system_mappings/sysmap_is_sealed.c  | 92 +++++++++++++++++++
> > >  1 file changed, 92 insertions(+)
> > >
> > > diff --git a/tools/testing/selftests/mseal_system_mappings/sysmap_is_sealed.c b/tools/testing/selftests/mseal_system_mappings/sysmap_is_sealed.c
> > > index ea75ad537620..83b4fadfbfe7 100644
> > > --- a/tools/testing/selftests/mseal_system_mappings/sysmap_is_sealed.c
> > > +++ b/tools/testing/selftests/mseal_system_mappings/sysmap_is_sealed.c
> >
> > Why on earth does 'mseal_system_mappings' have its own directory...??
> >
> > Ugh I don't know how I let this stuff go on the original series :/
> >
> > Please, for the love of all that's sacred, move these tests over to
> > tools/selftests/mm/. This is an mm feature, for our sins...
> >
> > You can do the move as a prerequisite patch in the series.
>
> Will do, I'll make the move the first patch.
>
> > (And, again, I really do insist on your change doing some cleanup here as
> > well rather than extending this stuff.)
>
> Yep, see my reply to 1/3.
>
> > > @@ -10,6 +10,7 @@
> > >  #include <unistd.h>
> > >  #include <string.h>
> > >  #include <stdbool.h>
> > > +#include <sys/mman.h>
> > >  #include <sys/utsname.h>
> > >  #include <zlib.h>
> > >
> > > @@ -232,4 +233,95 @@ TEST_F(basic, check_sealed)
> > >  	EXPECT_EQ(expected, sealed);
> > >  };
> > >
> > > +static bool find_vdso(unsigned long *start, unsigned long *end)
> > > +{
> > > +	char line[MAX_LINE_LEN];
> > > +	bool found = false;
> > > +	FILE *maps;
> > > +
> > > +	maps = fopen("/proc/self/maps", "r");
> > > +	if (!maps)
> > > +		return false;
> > > +
> > > +	while (fgets(line, sizeof(line), maps)) {
> > > +		if (strstr(line, "[vdso]") &&
> > > +		    sscanf(line, "%lx-%lx", start, end) == 2) {
> > > +			found = true;
> > > +			break;
> > > +		}
> > > +	}
> > > +
> > > +	fclose(maps);
> > > +	return found;
> > > +}
> >
> > There's shared code for this kind of thing, please don't duplicate a
> > /proc/self/maps thing if unnecessary. Also there's a nicer ioctl interface for
> > all this.
> >
> > See vm_utils.[ch].
>
> Oh thank you! I will use that.
>
> > I mean arguably this is an mremap test that belongs with mremap? I guess
> > debatable...
>
> Hmm, I'd lean towards keeping it with the sysmap test, since it's really
> testing that the seal is enforced on these mappings rather than anything
> about mremap() itself, but I don't feel strongly if you insist, just let me
> know.

Actually let's keep them together :) It's always a bit blurry...

>
> > This all just seems like work that should have been done in the past when this
> > feature was proposed, and doesn't depend on your changes at all AFAICT? Maybe I
> > missed it though.
> >
> > Valuable in itself, but probably worth sending separately as a result? Otherwise
> > it's a little disconnected from the actual change you're making.
>
> Yeah, it doesn't depend on it. I can send it separately on top of the move
> if you like, I just don't like touching things without tests where possible.

Well that's a good instinct for sure :)

I mean alternatively you could send as patch 1 and explicitly say you're
providing a tested foundation for the other changes.

>
> Thanks for the review!

No worries!

--
Cheers, Lorenzo