[PATCH] mm/mseal: fix mseal documentation for 32-bit kernels

[Pedro Falcato]

On Fri, Jul 03, 2026 at 10:50:29PM +0800, Leon Hwang wrote:
> On 2026/7/3 17:44, Pedro Falcato wrote:
> > On Fri, Jul 03, 2026 at 10:25:07AM +0800, Leon Hwang wrote:
> >> 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.
> >>
> >> Document the -EINTR return from mmap_write_lock_killable(), fix the
> >> CONFIG_MSEAL_SYSTEM_MAPPINGS typo, and describe system mappings in
> >> terms of VM_SEALED_SYSMAP.
> >>
> >> Signed-off-by: Leon Hwang <leon.hwang at linux.dev>
> >> ---
> >>  Documentation/userspace-api/mseal.rst | 18 ++++++++++--------
> >>  init/Kconfig                          |  2 +-
> >>  mm/mseal.c                            |  4 ++--
> >>  3 files changed, 13 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/Documentation/userspace-api/mseal.rst b/Documentation/userspace-api/mseal.rst
> >> index ea9b11a0bd89..1f1cf206670c 100644
> >> --- a/Documentation/userspace-api/mseal.rst
> >> +++ b/Documentation/userspace-api/mseal.rst
> >> @@ -50,8 +50,10 @@ 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.
> >> +      - **-EINTR**:
> >> +         * Interrupted while waiting for the mmap write lock.
> >> +      - **-ENOSYS**:
> >> +         * The kernel does not implement ``mseal()``.
> >>  
> >>     **Note about error return**:
> >>        - For above error cases, users can expect the given memory range is
> > 
> > Honestly, this whole thing needs to be deleted. We need a proper manpage.
> 
> $ man mseal
> No manual entry for mseal
> 
> When searching "mseal manual" using Google, this doc is the first entry.
> 
> So, this change is worthy.

Yes, I agree. To be clear, my main gripe is with the current state of things,
not your patch.
> 
> > 
> >> @@ -62,7 +64,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``.
> > 
> > This LGTM.
> > 
> >>  
> >>     **Idempotent**:
> >>        users can call mseal multiple times. mseal on an already sealed memory
> >> @@ -131,20 +134,19 @@ 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.
> > 
> > Also LGTM.
> > 
> >>  
> >>    If supported by an architecture (CONFIG_ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS),
> >> -  the CONFIG_MSEAL_SYSTEM_MAPPINGS seals all system mappings of this
> >> -  architecture.
> >> +  CONFIG_MSEAL_SYSTEM_MAPPINGS seals mappings marked with VM_SEALED_SYSMAP.
> > 
> > VM_SEALED_SYSMAP isn't meaningful to userspace.
> 
> 
> Got it. Will drop this change.
> 
> > 
> >>  
> >>    The following architectures currently support this feature: x86-64, arm64,
> >> -  loongarch and s390.
> >> +  loongarch, riscv, and s390.
> > 
> > This is also useless, every 64-bit architecture will support this.
> 
> 
> Do you mean dropping this sentence, or this change?

This sentence (this is not architecture specific...).

> 
> > 
> >>  
> >>    WARNING: This feature breaks programs which rely on relocating
> >>    or unmapping system mappings. Known broken software at the time
> >> diff --git a/init/Kconfig b/init/Kconfig
> >> index 5230d4879b1c..12bb39f637b1 100644
> >> --- a/init/Kconfig
> >> +++ b/init/Kconfig
> >> @@ -2112,7 +2112,7 @@ config ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS
> >>  	  from a kernel perspective.
> >>  
> >>  	  After the architecture enables this, a distribution can set
> >> -	  CONFIG_MSEAL_SYSTEM_MAPPING to manage access to the feature.
> >> +	  CONFIG_MSEAL_SYSTEM_MAPPINGS to manage access to the feature.
> >>  
> >>  	  For complete descriptions of memory sealing, please see
> >>  	  Documentation/userspace-api/mseal.rst
> >> diff --git a/mm/mseal.c b/mm/mseal.c
> >> index 9781647483d1..0464c7b94ab9 100644
> >> --- a/mm/mseal.c
> >> +++ b/mm/mseal.c
> >> @@ -132,8 +132,8 @@ static int mseal_apply(struct mm_struct *mm,
> >>   *   addr is not a valid address (not allocated).
> >>   *   end (start + len) is not a valid address.
> >>   *   a gap (unallocated memory) between start and end.
> >> - *  -EPERM:
> >> - *  - In 32 bit architecture, sealing is not supported.
> >> + *  -EINTR:
> >> + *   interrupted while waiting for the mmap write lock.
> >>   * Note:
> >>   *  user can call mseal(2) multiple times, adding a seal on an
> >>   *  already sealed memory is a no-action (no error).
> > 
> > And this whole header needs to be deleted as well. No one's looking at
> > kernel code for documentation (and if they are, we did a horrendous job
> > at actually documenting the thing).
> > 
> 
> Just to confirm, do you mean removing the entire function comment above
> do_mseal()?

Yes. Again, not your fault, just old gripes :)

-- 
Pedro