summaryrefslogtreecommitdiff
path: root/Documentation/userspace-api
diff options
context:
space:
mode:
authorLeon Hwang <leon.hwang@linux.dev>2026-07-15 21:12:58 +0800
committerAndrew Morton <akpm@linux-foundation.org>2026-08-06 18:57:12 -0700
commite474ac24a79211f83e214d856630829f77363459 (patch)
treec1a82a74e28cc0828cf90a89fcc822d623d67952 /Documentation/userspace-api
parent1b300f679a4c27127effed80ede6a99fd1862dd8 (diff)
downloadlinux-next-e474ac24a79211f83e214d856630829f77363459.tar.gz
linux-next-e474ac24a79211f83e214d856630829f77363459.zip
mm/mseal: fix mseal documentation for 32-bit kernels
mseal.o is built only for 64-bit kernels, so 32-bit kernels fall back to sys_ni_syscall() and return -ENOSYS rather than -EPERM. Drop architecture description in mseal.rst, since the arch feature doc has the latest state of mseal for each architecture. Fix the CONFIG_MSEAL_SYSTEM_MAPPINGS typo in init/Kconfig. Link: https://lore.kernel.org/20260715131258.55499-1-leon.hwang@linux.dev Signed-off-by: Leon Hwang <leon.hwang@linux.dev> Acked-by: Lance Yang <lance.yang@linux.dev> Cc: Alice Ryhl <aliceryhl@google.com> Cc: Anand Moon <linux.amoon@gmail.com> Cc: Doug Anderson <dianders@chromium.org> Cc: Gary Guo <gary@garyguo.net> Cc: Jann Horn <jannh@google.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Leon Hwang <leon.hwang@linux.dev> Cc: Liam R. Howlett <liam@infradead.org> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Miguel Ojeda <ojeda@kernel.org> Cc: Nathan Chancellor <nathan@kernel.org> Cc: Pedro Falcato <pfalcato@suse.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Cc: Vlastimil Babka <vbabka@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Diffstat (limited to 'Documentation/userspace-api')
-rw-r--r--Documentation/userspace-api/mseal.rst14
1 files changed, 6 insertions, 8 deletions
diff --git a/Documentation/userspace-api/mseal.rst b/Documentation/userspace-api/mseal.rst
index ea9b11a0bd89..c039d782f9f5 100644
--- a/Documentation/userspace-api/mseal.rst
+++ b/Documentation/userspace-api/mseal.rst
@@ -50,8 +50,8 @@ mseal syscall signature
* The start address (``addr``) is not allocated.
* The end address (``addr`` + ``len``) is not allocated.
* A gap (unallocated memory) between start and end address.
- - **-EPERM**:
- * sealing is supported only on 64-bit CPUs, 32-bit is not supported.
+ - **-ENOSYS**:
+ * The kernel does not implement ``mseal()``.
**Note about error return**:
- For above error cases, users can expect the given memory range is
@@ -62,7 +62,8 @@ mseal syscall signature
memory range could happen. However, those cases should be rare.
**Architecture support**:
- mseal only works on 64-bit CPUs, not 32-bit CPUs.
+ mseal is built only for 64-bit kernels. 32-bit kernels return
+ ``-ENOSYS``.
**Idempotent**:
users can call mseal multiple times. mseal on an already sealed memory
@@ -131,11 +132,11 @@ Use cases
- Chrome browser: protect some security sensitive data structures.
- System mappings:
- The system mappings are created by the kernel and includes vdso, vvar,
+ The system mappings are created by the kernel and include vdso, vvar,
vvar_vclock, vectors (arm compat-mode), sigpage (arm compat-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
+ protect them from ever changing to writable or unmapped/remapped as different
attributes. This is useful to mitigate memory corruption issues where a
corrupted pointer is passed to a memory management system.
@@ -143,9 +144,6 @@ Use cases
the CONFIG_MSEAL_SYSTEM_MAPPINGS seals all system mappings of this
architecture.
- The following architectures currently support this feature: x86-64, arm64,
- loongarch and s390.
-
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