From: Jeff Xu <jeffxu@chromium.org>

Update memory sealing documentation to include details about system
mappings.

Signed-off-by: Jeff Xu <jeffxu@chromium.org>
Reviewed-by: Kees Cook <kees@kernel.org>
---
 Documentation/userspace-api/mseal.rst | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/Documentation/userspace-api/mseal.rst b/Documentation/userspace-api/mseal.rst
index 41102f74c5e2..76e10938302a 100644
--- a/Documentation/userspace-api/mseal.rst
+++ b/Documentation/userspace-api/mseal.rst
@@ -130,6 +130,26 @@ Use cases
 
 - Chrome browser: protect some security sensitive data structures.
 
+- System mappings:
+  The system mappings are created by the kernel and includes vdso, vvar,
+  vvar_vclock, vectors (arm compact-mode), sigpage (arm compact-mode), uprobes.
+
+  Those system mappings are readonly only or execute only, memory sealing can
+  protect them from ever changing to writable or unmmap/remapped as different
+  attributes. This is useful to mitigate memory corruption issues where a
+  corrupted pointer is passed to a memory management system.
+
+  If supported by an architecture (CONFIG_ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS),
+  the CONFIG_MSEAL_SYSTEM_MAPPINGS seals all system mappings of this
+  architecture.
+
+  The following architectures currently support this feature: x86-64 and arm64.
+
+  WARNING: This feature breaks programs which rely on relocating
+  or unmapping system mappings. Known broken software at the time
+  of writing includes CHECKPOINT_RESTORE, UML, gVisor, rr. Therefore
+  this config can't be enabled universally.
+
 When not to use mseal
 =====================
 Applications can apply sealing to any virtual memory region from userspace,
-- 
2.48.1.711.g2feabab25a-goog

* jeffxu@chromium.org <jeffxu@chromium.org> [250303 00:09]:
> From: Jeff Xu <jeffxu@chromium.org>
> 
> Update memory sealing documentation to include details about system
> mappings.
> 
> Signed-off-by: Jeff Xu <jeffxu@chromium.org>
> Reviewed-by: Kees Cook <kees@kernel.org>

Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com>

> ---
>  Documentation/userspace-api/mseal.rst | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
> 
> diff --git a/Documentation/userspace-api/mseal.rst b/Documentation/userspace-api/mseal.rst
> index 41102f74c5e2..76e10938302a 100644
> --- a/Documentation/userspace-api/mseal.rst
> +++ b/Documentation/userspace-api/mseal.rst
> @@ -130,6 +130,26 @@ Use cases
>  
>  - Chrome browser: protect some security sensitive data structures.
>  
> +- System mappings:
> +  The system mappings are created by the kernel and includes vdso, vvar,
> +  vvar_vclock, vectors (arm compact-mode), sigpage (arm compact-mode), uprobes.
> +
> +  Those system mappings are readonly only or execute only, memory sealing can
> +  protect them from ever changing to writable or unmmap/remapped as different
> +  attributes. This is useful to mitigate memory corruption issues where a
> +  corrupted pointer is passed to a memory management system.
> +
> +  If supported by an architecture (CONFIG_ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS),
> +  the CONFIG_MSEAL_SYSTEM_MAPPINGS seals all system mappings of this
> +  architecture.
> +
> +  The following architectures currently support this feature: x86-64 and arm64.
> +
> +  WARNING: This feature breaks programs which rely on relocating
> +  or unmapping system mappings. Known broken software at the time
> +  of writing includes CHECKPOINT_RESTORE, UML, gVisor, rr. Therefore
> +  this config can't be enabled universally.
> +
>  When not to use mseal
>  =====================
>  Applications can apply sealing to any virtual memory region from userspace,
> -- 
> 2.48.1.711.g2feabab25a-goog
>

On Mon, Mar 03, 2025 at 05:09:20AM +0000, jeffxu@chromium.org wrote:
> From: Jeff Xu <jeffxu@chromium.org>
>
> Update memory sealing documentation to include details about system
> mappings.
>
> Signed-off-by: Jeff Xu <jeffxu@chromium.org>
> Reviewed-by: Kees Cook <kees@kernel.org>

LGTM so:

Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>

> ---
>  Documentation/userspace-api/mseal.rst | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
>
> diff --git a/Documentation/userspace-api/mseal.rst b/Documentation/userspace-api/mseal.rst
> index 41102f74c5e2..76e10938302a 100644
> --- a/Documentation/userspace-api/mseal.rst
> +++ b/Documentation/userspace-api/mseal.rst
> @@ -130,6 +130,26 @@ Use cases
>
>  - Chrome browser: protect some security sensitive data structures.
>
> +- System mappings:
> +  The system mappings are created by the kernel and includes vdso, vvar,
> +  vvar_vclock, vectors (arm compact-mode), sigpage (arm compact-mode), uprobes.
> +
> +  Those system mappings are readonly only or execute only, memory sealing can
> +  protect them from ever changing to writable or unmmap/remapped as different
> +  attributes. This is useful to mitigate memory corruption issues where a
> +  corrupted pointer is passed to a memory management system.
> +
> +  If supported by an architecture (CONFIG_ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS),
> +  the CONFIG_MSEAL_SYSTEM_MAPPINGS seals all system mappings of this
> +  architecture.
> +
> +  The following architectures currently support this feature: x86-64 and arm64.
> +
> +  WARNING: This feature breaks programs which rely on relocating
> +  or unmapping system mappings. Known broken software at the time
> +  of writing includes CHECKPOINT_RESTORE, UML, gVisor, rr. Therefore
> +  this config can't be enabled universally.

Perfect, thanks!

> +
>  When not to use mseal
>  =====================
>  Applications can apply sealing to any virtual memory region from userspace,
> --
> 2.48.1.711.g2feabab25a-goog
>