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

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

[Leon Hwang]

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@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
@@ -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``.
 
    **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.
 
   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.
 
   The following architectures currently support this feature: x86-64, arm64,
-  loongarch and s390.
+  loongarch, riscv, and s390.
 
   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).
-- 
2.54.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Lance Yang]

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@linux.dev>
>---

Thanks, free free to add:

Acked-by: Lance Yang <lance.yang@linux.dev>

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Thomas Weißschuh]

On Fri, Jul 03, 2026 at 10:25:07AM +0800, Leon Hwang wrote:
(...)

>    The following architectures currently support this feature: x86-64, arm64,
> -  loongarch and s390.
> +  loongarch, riscv, and s390.

For per-architecture feature documentation we also have
Documentation/features/. Maybe move it there.

>  
>    WARNING: This feature breaks programs which rely on relocating
>    or unmapping system mappings. Known broken software at the time

(...)

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Leon Hwang]

On 2026/7/3 17:44, Thomas Weißschuh wrote:
> On Fri, Jul 03, 2026 at 10:25:07AM +0800, Leon Hwang wrote:
> (...)
> 
>>    The following architectures currently support this feature: x86-64, arm64,
>> -  loongarch and s390.
>> +  loongarch, riscv, and s390.
> 
> For per-architecture feature documentation we also have
> Documentation/features/. Maybe move it there.


Better to replace with a reference to the feature doc?

+  Refer to :doc:`features/core/mseal_sys_mappings/arch-support` for the
+  support status of each architecture.

Thanks,
Leon

> 
>>  
>>    WARNING: This feature breaks programs which rely on relocating
>>    or unmapping system mappings. Known broken software at the time
> 
> (...)


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Pedro Falcato]

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

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

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

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

-- 
Pedro

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Leon Hwang]

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

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

> 
>>  
>>    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()?

Thanks,
Leon



_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Matthew Wilcox]

On Fri, Jul 03, 2026 at 10:25:07AM +0800, Leon Hwang wrote:
> Document the -EINTR return from mmap_write_lock_killable(), fix the

No, you don't understand the whole concept of "killable".  If a
task receives a fatal signal, it dies before it returns to userspace.
So userspace never gets to see the -EINTR.  It's fine to document inside
the kernel that function foo() can return -EINTR, but it's pointless to
document it for userspace.

This is how "killable" differs from "interruptible".  Interruptible allows
non-fatal signals to wake a task, and then the task can see the -EINTR.
But many processes do not check the error code, and so read() and write()
(despite being documented as being able to return EINTR!)  do not do so
in practise.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Leon Hwang]

On 4/7/26 08:39, Matthew Wilcox wrote:
> On Fri, Jul 03, 2026 at 10:25:07AM +0800, Leon Hwang wrote:
>> Document the -EINTR return from mmap_write_lock_killable(), fix the
> 
> No, you don't understand the whole concept of "killable".  If a
> task receives a fatal signal, it dies before it returns to userspace.
> So userspace never gets to see the -EINTR.  It's fine to document inside
> the kernel that function foo() can return -EINTR, but it's pointless to
> document it for userspace.
> 
> This is how "killable" differs from "interruptible".  Interruptible allows
> non-fatal signals to wake a task, and then the task can see the -EINTR.
> But many processes do not check the error code, and so read() and write()
> (despite being documented as being able to return EINTR!)  do not do so
> in practise.


Thanks for your explanation.

Will drop the -EINTR documentation change from mseal.rst.

Thanks,
Leon


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv