[PATCH 0/3] mm/mseal: further cleanups

[PATCH 0/3] mm/mseal: further cleanups

[Lorenzo Stoakes (ARM)]

The mseal implementation is still rather confusing, so tighten things up a
little.

The only user of do_mseal() outside of the system call is the MMAP_PAGE_ZERO
process personality - retain better control over how mseal is utilised by
providing mseal_mmap_page_zero() for this instead.

The comments are overly long and confusion, so cut them down so they're a lot
clearer.

Remove confusing mm_struct params (mseal can not be used on remote mm's) and
wrap the actual system call logic into the system call declaration.

Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
---
Lorenzo Stoakes (ARM) (3):
      mm/mseal: remove superfluous comments, fix confusion around mm
      mm/mseal: limit scope of mseal address zero to address zero
      mm/mseal: remove further superfluous comments, do_mseal()

 fs/binfmt_elf.c    |   7 +--
 include/linux/mm.h |   8 +--
 mm/mseal.c         | 156 ++++++++++++++++++-----------------------------------
 3 files changed, 56 insertions(+), 115 deletions(-)
---
base-commit: 59c684a9908d2e6f7a791f7f033eae57ec2b3a61
change-id: 20260716-mseal-fixups-131ad0939de2

Cheers,
-- 
Lorenzo Stoakes (ARM) <ljs@kernel.org>

[PATCH 1/3] mm/mseal: remove superfluous comments, fix confusion around mm

[Lorenzo Stoakes (ARM)]

Remove comment blocks that don't add value and eliminate any confusion
about whether or not we permit mseal()'ing of remote mm's by explicitly
referencing current->mm consistently.

Also avoid ugly goto by using an else branch.

No functional change intended.

Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
---
 mm/mseal.c | 48 ++++++++----------------------------------------
 1 file changed, 8 insertions(+), 40 deletions(-)

diff --git a/mm/mseal.c b/mm/mseal.c
index 9781647483d1..207fea89c61e 100644
--- a/mm/mseal.c
+++ b/mm/mseal.c
@@ -16,28 +16,7 @@
 #include <linux/sched.h>
 #include "internal.h"
 
-/*
- * mseal() disallows an input range which contain unmapped ranges (VMA holes).
- *
- * It disallows unmapped regions from start to end whether they exist at the
- * start, in the middle, or at the end of the range, or any combination thereof.
- *
- * This is because after sealing a range, there's nothing to stop memory mapping
- * of ranges in the remaining gaps later, meaning that the user might then
- * wrongly consider the entirety of the mseal()'d range to be sealed when it
- * in fact isn't.
- */
-
-/*
- * Does the [start, end) range contain any unmapped memory?
- *
- * We ensure that:
- * - start is part of a valid VMA.
- * - end is part of a valid VMA.
- * - no gap (unallocated memory) exists between start and end.
- */
-static bool range_contains_unmapped(struct mm_struct *mm,
-		unsigned long start, unsigned long end)
+static bool range_contains_unmapped(unsigned long start, unsigned long end)
 {
 	struct vm_area_struct *vma;
 	unsigned long prev_end = start;
@@ -53,11 +32,10 @@ static bool range_contains_unmapped(struct mm_struct *mm,
 	return prev_end < end;
 }
 
-static int mseal_apply(struct mm_struct *mm,
-		unsigned long start, unsigned long end)
+static int mseal_apply(unsigned long start, unsigned long end)
 {
 	struct vm_area_struct *vma, *prev;
-	VMA_ITERATOR(vmi, mm, start);
+	VMA_ITERATOR(vmi, current->mm, start);
 
 	/* We know there are no gaps so this will be non-NULL. */
 	vma = vma_iter_load(&vmi);
@@ -145,7 +123,6 @@ int do_mseal(unsigned long start, size_t len_in, unsigned long flags)
 	size_t len;
 	int ret = 0;
 	unsigned long end;
-	struct mm_struct *mm = current->mm;
 
 	/* Verify flags not set. */
 	if (flags)
@@ -167,24 +144,15 @@ int do_mseal(unsigned long start, size_t len_in, unsigned long flags)
 	if (end == start)
 		return 0;
 
-	if (mmap_write_lock_killable(mm))
+	if (mmap_write_lock_killable(current->mm))
 		return -EINTR;
 
-	if (range_contains_unmapped(mm, start, end)) {
+	if (range_contains_unmapped(start, end))
 		ret = -ENOMEM;
-		goto out;
-	}
-
-	/*
-	 * Second pass, this should success, unless there are errors
-	 * from vma_modify_flags, e.g. merge/split error, or process
-	 * reaching the max supported VMAs, however, those cases shall
-	 * be rare.
-	 */
-	ret = mseal_apply(mm, start, end);
+	else
+		ret = mseal_apply(start, end);
 
-out:
-	mmap_write_unlock(mm);
+	mmap_write_unlock(current->mm);
 	return ret;
 }
 

-- 
2.55.0

Re: [PATCH 1/3] mm/mseal: remove superfluous comments, fix confusion around mm

[Pedro Falcato]

On Thu, Jul 16, 2026 at 02:43:09PM +0100, Lorenzo Stoakes (ARM) wrote:
> Remove comment blocks that don't add value and eliminate any confusion
> about whether or not we permit mseal()'ing of remote mm's by explicitly
> referencing current->mm consistently.
> 
> Also avoid ugly goto by using an else branch.
> 
> No functional change intended.
> 
> Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>

Reviewed-by: Pedro Falcato <pfalcato@suse.de> 

-- 
Pedro

Re: [PATCH 1/3] mm/mseal: remove superfluous comments, fix confusion around mm

[David Hildenbrand (Arm)]

On 7/16/26 15:43, Lorenzo Stoakes (ARM) wrote:
> Remove comment blocks that don't add value and eliminate any confusion
> about whether or not we permit mseal()'ing of remote mm's by explicitly
> referencing current->mm consistently.
> 
> Also avoid ugly goto by using an else branch.
> 
> No functional change intended.
> 
> Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
> ---
>  mm/mseal.c | 48 ++++++++----------------------------------------
>  1 file changed, 8 insertions(+), 40 deletions(-)
> 
> diff --git a/mm/mseal.c b/mm/mseal.c
> index 9781647483d1..207fea89c61e 100644
> --- a/mm/mseal.c
> +++ b/mm/mseal.c
> @@ -16,28 +16,7 @@
>  #include <linux/sched.h>
>  #include "internal.h"
>  
> -/*
> - * mseal() disallows an input range which contain unmapped ranges (VMA holes).
> - *
> - * It disallows unmapped regions from start to end whether they exist at the
> - * start, in the middle, or at the end of the range, or any combination thereof.
> - *
> - * This is because after sealing a range, there's nothing to stop memory mapping
> - * of ranges in the remaining gaps later, meaning that the user might then
> - * wrongly consider the entirety of the mseal()'d range to be sealed when it
> - * in fact isn't.
> - */
> -
> -/*
> - * Does the [start, end) range contain any unmapped memory?
> - *
> - * We ensure that:
> - * - start is part of a valid VMA.
> - * - end is part of a valid VMA.
> - * - no gap (unallocated memory) exists between start and end.
> - */
> -static bool range_contains_unmapped(struct mm_struct *mm,
> -		unsigned long start, unsigned long end)
> +static bool range_contains_unmapped(unsigned long start, unsigned long end)
>  {
>  	struct vm_area_struct *vma;
>  	unsigned long prev_end = start;
> @@ -53,11 +32,10 @@ static bool range_contains_unmapped(struct mm_struct *mm,
>  	return prev_end < end;
>  }
>  
> -static int mseal_apply(struct mm_struct *mm,
> -		unsigned long start, unsigned long end)
> +static int mseal_apply(unsigned long start, unsigned long end)
>  {
>  	struct vm_area_struct *vma, *prev;

I guess using

struct mm_struct *mm = current->mm;

would reduce the churn?


Anyhow

Acked-by: David Hildenbrand (Arm) <david@kernel.org>

-- 
Cheers,

David

Re: [PATCH 1/3] mm/mseal: remove superfluous comments, fix confusion around mm

[Lorenzo Stoakes (ARM)]

On Fri, Jul 17, 2026 at 11:33:13AM +0100, David Hildenbrand (Arm) wrote:
> On 7/16/26 15:43, Lorenzo Stoakes (ARM) wrote:
> > Remove comment blocks that don't add value and eliminate any confusion
> > about whether or not we permit mseal()'ing of remote mm's by explicitly
> > referencing current->mm consistently.
> >
> > Also avoid ugly goto by using an else branch.
> >
> > No functional change intended.
> >
> > Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
> > ---
> >  mm/mseal.c | 48 ++++++++----------------------------------------
> >  1 file changed, 8 insertions(+), 40 deletions(-)
> >
> > diff --git a/mm/mseal.c b/mm/mseal.c
> > index 9781647483d1..207fea89c61e 100644
> > --- a/mm/mseal.c
> > +++ b/mm/mseal.c
> > @@ -16,28 +16,7 @@
> >  #include <linux/sched.h>
> >  #include "internal.h"
> >
> > -/*
> > - * mseal() disallows an input range which contain unmapped ranges (VMA holes).
> > - *
> > - * It disallows unmapped regions from start to end whether they exist at the
> > - * start, in the middle, or at the end of the range, or any combination thereof.
> > - *
> > - * This is because after sealing a range, there's nothing to stop memory mapping
> > - * of ranges in the remaining gaps later, meaning that the user might then
> > - * wrongly consider the entirety of the mseal()'d range to be sealed when it
> > - * in fact isn't.
> > - */
> > -
> > -/*
> > - * Does the [start, end) range contain any unmapped memory?
> > - *
> > - * We ensure that:
> > - * - start is part of a valid VMA.
> > - * - end is part of a valid VMA.
> > - * - no gap (unallocated memory) exists between start and end.
> > - */
> > -static bool range_contains_unmapped(struct mm_struct *mm,
> > -		unsigned long start, unsigned long end)
> > +static bool range_contains_unmapped(unsigned long start, unsigned long end)
> >  {
> >  	struct vm_area_struct *vma;
> >  	unsigned long prev_end = start;
> > @@ -53,11 +32,10 @@ static bool range_contains_unmapped(struct mm_struct *mm,
> >  	return prev_end < end;
> >  }
> >
> > -static int mseal_apply(struct mm_struct *mm,
> > -		unsigned long start, unsigned long end)
> > +static int mseal_apply(unsigned long start, unsigned long end)
> >  {
> >  	struct vm_area_struct *vma, *prev;
>
> I guess using
>
> struct mm_struct *mm = current->mm;
>
> would reduce the churn?

Ah yeah true, I avoided that pattern in general because of confusion that
arose from it before. Maybe over conservative :) can change on respin.

>
>
> Anyhow
>
> Acked-by: David Hildenbrand (Arm) <david@kernel.org>

Thanks!

>
> --
> Cheers,
>
> David

Cheers, Lorenzo

[PATCH 2/3] mm/mseal: limit scope of mseal address zero to address zero

[Lorenzo Stoakes (ARM)]

Commit 44f65d900698 ("binfmt_elf: mseal address zero") unconditionally
provided do_mseal() to any internal kernel caller in order to address a
corner case slated for possible removal.

It also incorrectly attempts to mseal() without checking to see whether the
mapping even succeeded.

Restrict the scope to the corner case by providing mseal_mmap_page_zero()
which asserts the MMAP_PAGE_ZERO personality.

Avoid unnecessary checks in the start, end range by abstracting the actual
mseal()'ing to mseal() and have mseal_mmap_page_zero() call that instead.

Only try to seal the VMA if we mapped the VMA.

Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
---
 fs/binfmt_elf.c    |  7 ++-----
 include/linux/mm.h |  8 ++------
 mm/mseal.c         | 48 +++++++++++++++++++++++++++++++++++-------------
 3 files changed, 39 insertions(+), 24 deletions(-)

diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 16a56b6b3f6c..e3131a311995 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1353,11 +1353,8 @@ static int load_elf_binary(struct linux_binprm *bprm)
 		   emulate the SVr4 behavior. Sigh. */
 		error = vm_mmap(NULL, 0, PAGE_SIZE, PROT_READ | PROT_EXEC,
 				MAP_FIXED | MAP_PRIVATE, 0);
-
-		retval = do_mseal(0, PAGE_SIZE, 0);
-		if (retval)
-			pr_warn_ratelimited("pid=%d, couldn't seal address 0, ret=%d.\n",
-					    task_pid_nr(current), retval);
+		if (!error)
+			mseal_mmap_page_zero();
 	}
 
 	regs = current_pt_regs();
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 550fb92957d1..87feaa5a2b78 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -5291,13 +5291,9 @@ int reserve_mem_find_by_name(const char *name, phys_addr_t *start, phys_addr_t *
 int reserve_mem_release_by_name(const char *name);
 
 #ifdef CONFIG_64BIT
-int do_mseal(unsigned long start, size_t len_in, unsigned long flags);
+void mseal_mmap_page_zero(void);
 #else
-static inline int do_mseal(unsigned long start, size_t len_in, unsigned long flags)
-{
-	/* noop on 32 bit */
-	return 0;
-}
+static inline void mseal_mmap_page_zero(void) {}
 #endif
 
 /*
diff --git a/mm/mseal.c b/mm/mseal.c
index 207fea89c61e..5930551d84f2 100644
--- a/mm/mseal.c
+++ b/mm/mseal.c
@@ -32,7 +32,7 @@ static bool range_contains_unmapped(unsigned long start, unsigned long end)
 	return prev_end < end;
 }
 
-static int mseal_apply(unsigned long start, unsigned long end)
+static int __mseal(unsigned long start, unsigned long end)
 {
 	struct vm_area_struct *vma, *prev;
 	VMA_ITERATOR(vmi, current->mm, start);
@@ -66,6 +66,38 @@ static int mseal_apply(unsigned long start, unsigned long end)
 	return 0;
 }
 
+static int mseal(unsigned long start, unsigned long end)
+{
+	int err;
+
+	err = mmap_write_lock_killable(current->mm);
+	if (err)
+		return err;
+	if (range_contains_unmapped(start, end))
+		err = -ENOMEM;
+	else
+		err = __mseal(start, end);
+	mmap_write_unlock(current->mm);
+	return err;
+}
+
+/**
+ * mseal_mmap_page_zero() - If the MMAP_PAGE_ZERO personality is set, mseal()
+ * the page mapped at address zero.
+ */
+void mseal_mmap_page_zero(void)
+{
+	int err;
+
+	if (WARN_ON_ONCE(!(current->personality & MMAP_PAGE_ZERO)))
+		return;
+
+	err = mseal(0, PAGE_SIZE);
+	if (err)
+		pr_warn_ratelimited("pid=%d, couldn't seal address 0, ret=%d.\n",
+				    task_pid_nr(current), err);
+}
+
 /*
  * mseal(2) seals the VM's meta data from
  * selected syscalls.
@@ -118,10 +150,9 @@ static int mseal_apply(unsigned long start, unsigned long end)
  *
  *  unseal() is not supported.
  */
-int do_mseal(unsigned long start, size_t len_in, unsigned long flags)
+static int do_mseal(unsigned long start, size_t len_in, unsigned long flags)
 {
 	size_t len;
-	int ret = 0;
 	unsigned long end;
 
 	/* Verify flags not set. */
@@ -144,16 +175,7 @@ int do_mseal(unsigned long start, size_t len_in, unsigned long flags)
 	if (end == start)
 		return 0;
 
-	if (mmap_write_lock_killable(current->mm))
-		return -EINTR;
-
-	if (range_contains_unmapped(start, end))
-		ret = -ENOMEM;
-	else
-		ret = mseal_apply(start, end);
-
-	mmap_write_unlock(current->mm);
-	return ret;
+	return mseal(start, end);
 }
 
 SYSCALL_DEFINE3(mseal, unsigned long, start, size_t, len, unsigned long,

-- 
2.55.0

Re: [PATCH 2/3] mm/mseal: limit scope of mseal address zero to address zero

[Pedro Falcato]

On Thu, Jul 16, 2026 at 02:43:10PM +0100, Lorenzo Stoakes (ARM) wrote:
> Commit 44f65d900698 ("binfmt_elf: mseal address zero") unconditionally
> provided do_mseal() to any internal kernel caller in order to address a
> corner case slated for possible removal.
> 
> It also incorrectly attempts to mseal() without checking to see whether the
> mapping even succeeded.
> 
> Restrict the scope to the corner case by providing mseal_mmap_page_zero()
> which asserts the MMAP_PAGE_ZERO personality.
> 
> Avoid unnecessary checks in the start, end range by abstracting the actual
> mseal()'ing to mseal() and have mseal_mmap_page_zero() call that instead.
> 
> Only try to seal the VMA if we mapped the VMA.
> 
> Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
> ---
>  fs/binfmt_elf.c    |  7 ++-----
>  include/linux/mm.h |  8 ++------
>  mm/mseal.c         | 48 +++++++++++++++++++++++++++++++++++-------------
>  3 files changed, 39 insertions(+), 24 deletions(-)
> 
> diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> index 16a56b6b3f6c..e3131a311995 100644
> --- a/fs/binfmt_elf.c
> +++ b/fs/binfmt_elf.c
> @@ -1353,11 +1353,8 @@ static int load_elf_binary(struct linux_binprm *bprm)
>  		   emulate the SVr4 behavior. Sigh. */
>  		error = vm_mmap(NULL, 0, PAGE_SIZE, PROT_READ | PROT_EXEC,
>  				MAP_FIXED | MAP_PRIVATE, 0);

I think pedantically load_elf_binary() should error out on mmap error, no?
Not that this personality is used in the big 2026 however...

> -
> -		retval = do_mseal(0, PAGE_SIZE, 0);
> -		if (retval)
> -			pr_warn_ratelimited("pid=%d, couldn't seal address 0, ret=%d.\n",
> -					    task_pid_nr(current), retval);
> +		if (!error)
> +			mseal_mmap_page_zero();
>  	}
>  
>  	regs = current_pt_regs();
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 550fb92957d1..87feaa5a2b78 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -5291,13 +5291,9 @@ int reserve_mem_find_by_name(const char *name, phys_addr_t *start, phys_addr_t *
>  int reserve_mem_release_by_name(const char *name);
>  
>  #ifdef CONFIG_64BIT
> -int do_mseal(unsigned long start, size_t len_in, unsigned long flags);
> +void mseal_mmap_page_zero(void);
>  #else
> -static inline int do_mseal(unsigned long start, size_t len_in, unsigned long flags)
> -{
> -	/* noop on 32 bit */
> -	return 0;
> -}
> +static inline void mseal_mmap_page_zero(void) {}
>  #endif
>  
>  /*
> diff --git a/mm/mseal.c b/mm/mseal.c
> index 207fea89c61e..5930551d84f2 100644
> --- a/mm/mseal.c
> +++ b/mm/mseal.c
> @@ -32,7 +32,7 @@ static bool range_contains_unmapped(unsigned long start, unsigned long end)
>  	return prev_end < end;
>  }
>  
> -static int mseal_apply(unsigned long start, unsigned long end)
> +static int __mseal(unsigned long start, unsigned long end)

Why? I think the previous name is perfectly cromulent.

>  {
>  	struct vm_area_struct *vma, *prev;
>  	VMA_ITERATOR(vmi, current->mm, start);
> @@ -66,6 +66,38 @@ static int mseal_apply(unsigned long start, unsigned long end)
>  	return 0;
>  }
>  
> +static int mseal(unsigned long start, unsigned long end)

I don't like that you go start - end on a function called "mseal". The actual
system call goes start - len. It just looks confusing :) So either rename it
to mseal_range(), or make it take a start, length pair.

The overall spirit of the change LGTM however. 

-- 
Pedro

Re: [PATCH 2/3] mm/mseal: limit scope of mseal address zero to address zero

[Lorenzo Stoakes (ARM)]

On Thu, Jul 16, 2026 at 04:06:20PM +0100, Pedro Falcato wrote:
> On Thu, Jul 16, 2026 at 02:43:10PM +0100, Lorenzo Stoakes (ARM) wrote:
> > Commit 44f65d900698 ("binfmt_elf: mseal address zero") unconditionally
> > provided do_mseal() to any internal kernel caller in order to address a
> > corner case slated for possible removal.
> >
> > It also incorrectly attempts to mseal() without checking to see whether the
> > mapping even succeeded.
> >
> > Restrict the scope to the corner case by providing mseal_mmap_page_zero()
> > which asserts the MMAP_PAGE_ZERO personality.
> >
> > Avoid unnecessary checks in the start, end range by abstracting the actual
> > mseal()'ing to mseal() and have mseal_mmap_page_zero() call that instead.
> >
> > Only try to seal the VMA if we mapped the VMA.
> >
> > Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
> > ---
> >  fs/binfmt_elf.c    |  7 ++-----
> >  include/linux/mm.h |  8 ++------
> >  mm/mseal.c         | 48 +++++++++++++++++++++++++++++++++++-------------
> >  3 files changed, 39 insertions(+), 24 deletions(-)
> >
> > diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> > index 16a56b6b3f6c..e3131a311995 100644
> > --- a/fs/binfmt_elf.c
> > +++ b/fs/binfmt_elf.c
> > @@ -1353,11 +1353,8 @@ static int load_elf_binary(struct linux_binprm *bprm)
> >  		   emulate the SVr4 behavior. Sigh. */
> >  		error = vm_mmap(NULL, 0, PAGE_SIZE, PROT_READ | PROT_EXEC,
> >  				MAP_FIXED | MAP_PRIVATE, 0);
>
> I think pedantically load_elf_binary() should error out on mmap error, no?
> Not that this personality is used in the big 2026 however...

I'm not sure I implied otherwise?

But yes I'm aware, the point is to not try to mseal() an unmapped range knowingly.

The fact we 'get away with it' now is irrelevant.

I can update the commit message if a respin is necessary to spell this out (I
thought it was obvious).

>
> > -
> > -		retval = do_mseal(0, PAGE_SIZE, 0);
> > -		if (retval)
> > -			pr_warn_ratelimited("pid=%d, couldn't seal address 0, ret=%d.\n",
> > -					    task_pid_nr(current), retval);
> > +		if (!error)
> > +			mseal_mmap_page_zero();
> >  	}
> >
> >  	regs = current_pt_regs();
> > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > index 550fb92957d1..87feaa5a2b78 100644
> > --- a/include/linux/mm.h
> > +++ b/include/linux/mm.h
> > @@ -5291,13 +5291,9 @@ int reserve_mem_find_by_name(const char *name, phys_addr_t *start, phys_addr_t *
> >  int reserve_mem_release_by_name(const char *name);
> >
> >  #ifdef CONFIG_64BIT
> > -int do_mseal(unsigned long start, size_t len_in, unsigned long flags);
> > +void mseal_mmap_page_zero(void);
> >  #else
> > -static inline int do_mseal(unsigned long start, size_t len_in, unsigned long flags)
> > -{
> > -	/* noop on 32 bit */
> > -	return 0;
> > -}
> > +static inline void mseal_mmap_page_zero(void) {}
> >  #endif
> >
> >  /*
> > diff --git a/mm/mseal.c b/mm/mseal.c
> > index 207fea89c61e..5930551d84f2 100644
> > --- a/mm/mseal.c
> > +++ b/mm/mseal.c
> > @@ -32,7 +32,7 @@ static bool range_contains_unmapped(unsigned long start, unsigned long end)
> >  	return prev_end < end;
> >  }
> >
> > -static int mseal_apply(unsigned long start, unsigned long end)
> > +static int __mseal(unsigned long start, unsigned long end)
>
> Why? I think the previous name is perfectly cromulent.

Because this is what actually mseal()'s, the _apply is not really useful.

The __ is because it's unlocked.

The point here is to eliminate useless indirection, so calling the function that
mseals, 'mseal' seems sensible.

>
> >  {
> >  	struct vm_area_struct *vma, *prev;
> >  	VMA_ITERATOR(vmi, current->mm, start);
> > @@ -66,6 +66,38 @@ static int mseal_apply(unsigned long start, unsigned long end)
> >  	return 0;
> >  }
> >
> > +static int mseal(unsigned long start, unsigned long end)
>
> I don't like that you go start - end on a function called "mseal". The actual
> system call goes start - len. It just looks confusing :) So either rename it
> to mseal_range(), or make it take a start, length pair.

I'm not sure I really understand the confusion (I suppose you're equally
confused by the lack of flags parameter?),

I find it silly that we avoid function names because a system call of the same
name exists.

But I guess I can rename it to mseal_range() since I don't want the series
blocked on silly naming issues.

The reason for passing end (which was already the case) is that the syscall
already calculates it and we need it to do the actual mseal.

>
> The overall spirit of the change LGTM however.

OK.

>
> --
> Pedro

Thanks, Lorenzo

Re: [PATCH 2/3] mm/mseal: limit scope of mseal address zero to address zero

[David Hildenbrand (Arm)]

>>
>>>  {
>>>  	struct vm_area_struct *vma, *prev;
>>>  	VMA_ITERATOR(vmi, current->mm, start);
>>> @@ -66,6 +66,38 @@ static int mseal_apply(unsigned long start, unsigned long end)
>>>  	return 0;
>>>  }
>>>
>>> +static int mseal(unsigned long start, unsigned long end)
>>
>> I don't like that you go start - end on a function called "mseal". The actual
>> system call goes start - len. It just looks confusing :) So either rename it
>> to mseal_range(), or make it take a start, length pair.
> 
> I'm not sure I really understand the confusion (I suppose you're equally
> confused by the lack of flags parameter?),
> 
> I find it silly that we avoid function names because a system call of the same
> name exists.
> 
> But I guess I can rename it to mseal_range() since I don't want the series
> blocked on silly naming issues.

I think we typically have a XXX call do_XXX, like with mprotect(). But not sure
if there is a real rule to that, I'm sure there are exceptions. At least it's
only an internal helper.

Just like with the "__*" functions, sometimes it indeed helps to just have a
better description that shows the difference. But sometimes it's just really
hard to name or restructure stuff.

I think the page fault logic is especially hard to follow with things like
do_fault() and __do_fault(), whereby we have another layer of do_read_fault()
etc in-between :)

-- 
Cheers,

David

Re: [PATCH 2/3] mm/mseal: limit scope of mseal address zero to address zero

[Lorenzo Stoakes (ARM)]

On Fri, Jul 17, 2026 at 11:41:11AM +0100, David Hildenbrand (Arm) wrote:
> >>
> >>>  {
> >>>  	struct vm_area_struct *vma, *prev;
> >>>  	VMA_ITERATOR(vmi, current->mm, start);
> >>> @@ -66,6 +66,38 @@ static int mseal_apply(unsigned long start, unsigned long end)
> >>>  	return 0;
> >>>  }
> >>>
> >>> +static int mseal(unsigned long start, unsigned long end)
> >>
> >> I don't like that you go start - end on a function called "mseal". The actual
> >> system call goes start - len. It just looks confusing :) So either rename it
> >> to mseal_range(), or make it take a start, length pair.
> >
> > I'm not sure I really understand the confusion (I suppose you're equally
> > confused by the lack of flags parameter?),
> >
> > I find it silly that we avoid function names because a system call of the same
> > name exists.
> >
> > But I guess I can rename it to mseal_range() since I don't want the series
> > blocked on silly naming issues.
>
> I think we typically have a XXX call do_XXX, like with mprotect(). But not sure
> if there is a real rule to that, I'm sure there are exceptions. At least it's
> only an internal helper.

Yeah I think that's more the pattern.

>
> Just like with the "__*" functions, sometimes it indeed helps to just have a
> better description that shows the difference. But sometimes it's just really
> hard to name or restructure stuff.

Yup :)

>
> I think the page fault logic is especially hard to follow with things like
> do_fault() and __do_fault(), whereby we have another layer of do_read_fault()
> etc in-between :)

Yeah we are consistently inconsistent also on top of that :)

In general on reflection I realise I was being a bit stubborn here and Pedro is
right - mseal_range() is much better, reflects the [start, end) vs. [start,
start + len) thing better.

Will respin with that changed.

>
> --
> Cheers,
>
> David

Thanks, Lorenzo

Re: [PATCH 2/3] mm/mseal: limit scope of mseal address zero to address zero

[David Hildenbrand (Arm)]

On 7/16/26 15:43, Lorenzo Stoakes (ARM) wrote:
> Commit 44f65d900698 ("binfmt_elf: mseal address zero") unconditionally
> provided do_mseal() to any internal kernel caller in order to address a
> corner case slated for possible removal.
> 
> It also incorrectly attempts to mseal() without checking to see whether the
> mapping even succeeded.
> 
> Restrict the scope to the corner case by providing mseal_mmap_page_zero()
> which asserts the MMAP_PAGE_ZERO personality.
> 
> Avoid unnecessary checks in the start, end range by abstracting the actual
> mseal()'ing to mseal() and have mseal_mmap_page_zero() call that instead.
> 
> Only try to seal the VMA if we mapped the VMA.
> 
> Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
> ---
>  fs/binfmt_elf.c    |  7 ++-----
>  include/linux/mm.h |  8 ++------
>  mm/mseal.c         | 48 +++++++++++++++++++++++++++++++++++-------------
>  3 files changed, 39 insertions(+), 24 deletions(-)
> 
> diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> index 16a56b6b3f6c..e3131a311995 100644
> --- a/fs/binfmt_elf.c
> +++ b/fs/binfmt_elf.c
> @@ -1353,11 +1353,8 @@ static int load_elf_binary(struct linux_binprm *bprm)
>  		   emulate the SVr4 behavior. Sigh. */
>  		error = vm_mmap(NULL, 0, PAGE_SIZE, PROT_READ | PROT_EXEC,
>  				MAP_FIXED | MAP_PRIVATE, 0);
> -
> -		retval = do_mseal(0, PAGE_SIZE, 0);
> -		if (retval)
> -			pr_warn_ratelimited("pid=%d, couldn't seal address 0, ret=%d.\n",
> -					    task_pid_nr(current), retval);
> +		if (!error)
> +			mseal_mmap_page_zero();
>  	}
>  
>  	regs = current_pt_regs();
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 550fb92957d1..87feaa5a2b78 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -5291,13 +5291,9 @@ int reserve_mem_find_by_name(const char *name, phys_addr_t *start, phys_addr_t *
>  int reserve_mem_release_by_name(const char *name);
>  
>  #ifdef CONFIG_64BIT
> -int do_mseal(unsigned long start, size_t len_in, unsigned long flags);
> +void mseal_mmap_page_zero(void);

do_mseal() gone here, nice.

>  #else
> -static inline int do_mseal(unsigned long start, size_t len_in, unsigned long flags)
> -{
> -	/* noop on 32 bit */
> -	return 0;
> -}
> +static inline void mseal_mmap_page_zero(void) {}
>  #endif
>  
>  /*
> diff --git a/mm/mseal.c b/mm/mseal.c
> index 207fea89c61e..5930551d84f2 100644
> --- a/mm/mseal.c
> +++ b/mm/mseal.c
> @@ -32,7 +32,7 @@ static bool range_contains_unmapped(unsigned long start, unsigned long end)
>  	return prev_end < end;
>  }
>  
> -static int mseal_apply(unsigned long start, unsigned long end)
> +static int __mseal(unsigned long start, unsigned long end)
>  {
>  	struct vm_area_struct *vma, *prev;
>  	VMA_ITERATOR(vmi, current->mm, start);
> @@ -66,6 +66,38 @@ static int mseal_apply(unsigned long start, unsigned long end)
>  	return 0;
>  }
>  
> +static int mseal(unsigned long start, unsigned long end)

mseal_range() could be indeed nicer. But do_mseal() is now a pure helper for
"SYSCALL_DEFINE3(mseal" only ...could we simply inline do_mseal into
SYSCALL_DEFINE3(mseal)?

We could do that separately, ofc.

-- 
Cheers,

David

Re: [PATCH 2/3] mm/mseal: limit scope of mseal address zero to address zero

[David Hildenbrand (Arm)]

>> -static inline int do_mseal(unsigned long start, size_t len_in, unsigned long flags)
>> -{
>> -	/* noop on 32 bit */
>> -	return 0;
>> -}
>> +static inline void mseal_mmap_page_zero(void) {}
>>  #endif
>>  
>>  /*
>> diff --git a/mm/mseal.c b/mm/mseal.c
>> index 207fea89c61e..5930551d84f2 100644
>> --- a/mm/mseal.c
>> +++ b/mm/mseal.c
>> @@ -32,7 +32,7 @@ static bool range_contains_unmapped(unsigned long start, unsigned long end)
>>  	return prev_end < end;
>>  }
>>  
>> -static int mseal_apply(unsigned long start, unsigned long end)
>> +static int __mseal(unsigned long start, unsigned long end)
>>  {
>>  	struct vm_area_struct *vma, *prev;
>>  	VMA_ITERATOR(vmi, current->mm, start);
>> @@ -66,6 +66,38 @@ static int mseal_apply(unsigned long start, unsigned long end)
>>  	return 0;
>>  }
>>  
>> +static int mseal(unsigned long start, unsigned long end)
> 
> mseal_range() could be indeed nicer. But do_mseal() is now a pure helper for
> "SYSCALL_DEFINE3(mseal" only ...could we simply inline do_mseal into
> SYSCALL_DEFINE3(mseal)?
> 
> We could do that separately, ofc.
> 

Forgot

Acked-by: David Hildenbrand (Arm) <david@kernel.org>

-- 
Cheers,

David

Re: [PATCH 2/3] mm/mseal: limit scope of mseal address zero to address zero

[Lorenzo Stoakes (ARM)]

On Fri, Jul 17, 2026 at 11:49:29AM +0100, David Hildenbrand (Arm) wrote:
>
> >> -static inline int do_mseal(unsigned long start, size_t len_in, unsigned long flags)
> >> -{
> >> -	/* noop on 32 bit */
> >> -	return 0;
> >> -}
> >> +static inline void mseal_mmap_page_zero(void) {}
> >>  #endif
> >>
> >>  /*
> >> diff --git a/mm/mseal.c b/mm/mseal.c
> >> index 207fea89c61e..5930551d84f2 100644
> >> --- a/mm/mseal.c
> >> +++ b/mm/mseal.c
> >> @@ -32,7 +32,7 @@ static bool range_contains_unmapped(unsigned long start, unsigned long end)
> >>  	return prev_end < end;
> >>  }
> >>
> >> -static int mseal_apply(unsigned long start, unsigned long end)
> >> +static int __mseal(unsigned long start, unsigned long end)
> >>  {
> >>  	struct vm_area_struct *vma, *prev;
> >>  	VMA_ITERATOR(vmi, current->mm, start);
> >> @@ -66,6 +66,38 @@ static int mseal_apply(unsigned long start, unsigned long end)
> >>  	return 0;
> >>  }
> >>
> >> +static int mseal(unsigned long start, unsigned long end)
> >
> > mseal_range() could be indeed nicer. But do_mseal() is now a pure helper for
> > "SYSCALL_DEFINE3(mseal" only ...could we simply inline do_mseal into
> > SYSCALL_DEFINE3(mseal)?
> >
> > We could do that separately, ofc.

Yeah I do this in 3/3 :P

> >
>
> Forgot
>
> Acked-by: David Hildenbrand (Arm) <david@kernel.org>

Thanks :)

>
> --
> Cheers,
>
> David

Cheers, Lorenzo

[PATCH 3/3] mm/mseal: remove further superfluous comments, do_mseal()

[Lorenzo Stoakes (ARM)]

There's no need to abstract do_mseal() any longer so put the system call
implementation in the system call declaration.

The comment around do_mseal() is strangely formatted, overly long and adds
a lot of superfluous information that the code already provides, so boil it
down to the essentials.

Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
---
 mm/mseal.c | 74 ++++++++++++++------------------------------------------------
 1 file changed, 16 insertions(+), 58 deletions(-)

diff --git a/mm/mseal.c b/mm/mseal.c
index 5930551d84f2..d01ab35d3f0f 100644
--- a/mm/mseal.c
+++ b/mm/mseal.c
@@ -99,60 +99,24 @@ void mseal_mmap_page_zero(void)
 }
 
 /*
- * mseal(2) seals the VM's meta data from
- * selected syscalls.
+ * Seal VMAs in the specified input range to prevent an attacker replacing what
+ * is mapped in the range with something else.
  *
- * addr/len: VM address range.
+ * Disallows:
+ * - VMA unmapping, remapping or shrinking.
+ * - Overwriting the VMA with another one via mmap(), mremap() or similar.
+ * - Alteration of properties via mprotect()/pkey_mprotect().
+ * - Destructive madvise() behaviours (like MADV_DONTNEED) on anonymous read-only
+ *   ranges.
  *
- *  The address range by addr/len must meet:
- *   start (addr) must be in a valid VMA.
- *   end (addr + len) must be in a valid VMA.
- *   no gap (unallocated memory) between start and end.
- *   start (addr) must be page aligned.
+ * Since unmapped ranges can be mapped at any time, the input range must span
+ * mapped ranges only.
  *
- *  len: len will be page aligned implicitly.
- *
- *   Below VMA operations are blocked after sealing.
- *   1> Unmapping, moving to another location, and shrinking
- *	the size, via munmap() and mremap(), can leave an empty
- *	space, therefore can be replaced with a VMA with a new
- *	set of attributes.
- *   2> Moving or expanding a different vma into the current location,
- *	via mremap().
- *   3> Modifying a VMA via mmap(MAP_FIXED).
- *   4> Size expansion, via mremap(), does not appear to pose any
- *	specific risks to sealed VMAs. It is included anyway because
- *	the use case is unclear. In any case, users can rely on
- *	merging to expand a sealed VMA.
- *   5> mprotect and pkey_mprotect.
- *   6> Some destructive madvice() behavior (e.g. MADV_DONTNEED)
- *      for anonymous memory, when users don't have write permission to the
- *	memory. Those behaviors can alter region contents by discarding pages,
- *	effectively a memset(0) for anonymous memory.
- *
- *  flags: reserved.
- *
- * return values:
- *  zero: success.
- *  -EINVAL:
- *   invalid input flags.
- *   start address is not page aligned.
- *   Address range (start + len) overflow.
- *  -ENOMEM:
- *   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.
- * Note:
- *  user can call mseal(2) multiple times, adding a seal on an
- *  already sealed memory is a no-action (no error).
- *
- *  unseal() is not supported.
+ * The flags parameter is currently reserved.
  */
-static int do_mseal(unsigned long start, size_t len_in, unsigned long flags)
+SYSCALL_DEFINE3(mseal, unsigned long, start, size_t, len, unsigned long, flags)
 {
-	size_t len;
+	size_t len_aligned;
 	unsigned long end;
 
 	/* Verify flags not set. */
@@ -163,12 +127,12 @@ static int do_mseal(unsigned long start, size_t len_in, unsigned long flags)
 	if (!PAGE_ALIGNED(start))
 		return -EINVAL;
 
-	len = PAGE_ALIGN(len_in);
+	len_aligned = PAGE_ALIGN(len);
 	/* Check to see whether len was rounded up from small -ve to zero. */
-	if (len_in && !len)
+	if (len && !len_aligned)
 		return -EINVAL;
 
-	end = start + len;
+	end = start + len_aligned;
 	if (end < start)
 		return -EINVAL;
 
@@ -177,9 +141,3 @@ static int do_mseal(unsigned long start, size_t len_in, unsigned long flags)
 
 	return mseal(start, end);
 }
-
-SYSCALL_DEFINE3(mseal, unsigned long, start, size_t, len, unsigned long,
-		flags)
-{
-	return do_mseal(start, len, flags);
-}

-- 
2.55.0

Re: [PATCH 3/3] mm/mseal: remove further superfluous comments, do_mseal()

[Pedro Falcato]

On Thu, Jul 16, 2026 at 02:43:11PM +0100, Lorenzo Stoakes (ARM) wrote:
> There's no need to abstract do_mseal() any longer so put the system call
> implementation in the system call declaration.

This looks great!

> 
> The comment around do_mseal() is strangely formatted, overly long and adds
> a lot of superfluous information that the code already provides, so boil it
> down to the essentials.

But I would much rather we delete the whole comment (like Leon's patch did,
per my request). Do you disagree?

> 
> Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>

Anyway,

Reviewed-by: Pedro Falcato <pfalcato@suse.de>

-- 
Pedro

Re: [PATCH 3/3] mm/mseal: remove further superfluous comments, do_mseal()

[Lorenzo Stoakes (ARM)]

On Thu, Jul 16, 2026 at 04:09:14PM +0100, Pedro Falcato wrote:
> On Thu, Jul 16, 2026 at 02:43:11PM +0100, Lorenzo Stoakes (ARM) wrote:
> > There's no need to abstract do_mseal() any longer so put the system call
> > implementation in the system call declaration.
>
> This looks great!
>
> >
> > The comment around do_mseal() is strangely formatted, overly long and adds
> > a lot of superfluous information that the code already provides, so boil it
> > down to the essentials.
>
> But I would much rather we delete the whole comment (like Leon's patch did,
> per my request). Do you disagree?

I would like us to retain the information I added yes. Removing that is not
really helpful I don't think.

>
> >
> > Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
>
> Anyway,
>
> Reviewed-by: Pedro Falcato <pfalcato@suse.de>

Thanks!

>
> --
> Pedro

Cheers, Lorenzo

Re: [PATCH 3/3] mm/mseal: remove further superfluous comments, do_mseal()

[Andrew Morton]

On Thu, 16 Jul 2026 14:43:11 +0100 "Lorenzo Stoakes (ARM)" <ljs@kernel.org> wrote:

> There's no need to abstract do_mseal() any longer so put the system call
> implementation in the system call declaration.
> 
> The comment around do_mseal() is strangely formatted, overly long and adds
> a lot of superfluous information that the code already provides, so boil it
> down to the essentials.
> 

This patch
(https://lore.kernel.org/20260716-mseal-fixups-v1-3-3a9609bf041b@kernel.org)
overlaps muchly with Leon's "mm/mseal: fix mseal documentation for
32-bit kernels"
(https://lore.kernel.org/20260715131258.55499-1-leon.hwang@linux.dev).

I'll remove the mseal.c changes from Leon's patch and I'll retain the
rest of that patch, after adjusting its changelog.  Please check all of
this!


Here's what's left of Leon's patch:

From: Leon Hwang <leon.hwang@linux.dev>
Subject: mm/mseal: fix mseal documentation for 32-bit kernels
Date: Wed, 15 Jul 2026 21:12:58 +0800

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

 Documentation/userspace-api/mseal.rst |   14 ++++++--------
 init/Kconfig                          |    2 +-
 2 files changed, 7 insertions(+), 9 deletions(-)

--- a/Documentation/userspace-api/mseal.rst~mm-mseal-fix-mseal-documentation-for-32-bit-kernels
+++ a/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
--- a/init/Kconfig~mm-mseal-fix-mseal-documentation-for-32-bit-kernels
+++ a/init/Kconfig
@@ -2120,7 +2120,7 @@ config ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPIN
 	  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
_

Re: [PATCH 3/3] mm/mseal: remove further superfluous comments, do_mseal()

[Lorenzo Stoakes (ARM)]

On Thu, Jul 16, 2026 at 05:33:55PM -0700, Andrew Morton wrote:
> On Thu, 16 Jul 2026 14:43:11 +0100 "Lorenzo Stoakes (ARM)" <ljs@kernel.org> wrote:
>
> > There's no need to abstract do_mseal() any longer so put the system call
> > implementation in the system call declaration.
> >
> > The comment around do_mseal() is strangely formatted, overly long and adds
> > a lot of superfluous information that the code already provides, so boil it
> > down to the essentials.
> >
>
> This patch
> (https://lore.kernel.org/20260716-mseal-fixups-v1-3-3a9609bf041b@kernel.org)
> overlaps muchly with Leon's "mm/mseal: fix mseal documentation for
> 32-bit kernels"
> (https://lore.kernel.org/20260715131258.55499-1-leon.hwang@linux.dev).
>
> I'll remove the mseal.c changes from Leon's patch and I'll retain the
> rest of that patch, after adjusting its changelog.  Please check all of
> this!

Thanks! And sorry Leon - we definitely don't need the majority of the
comments in mseal.c - so this change essentially makes those changes of
yours unnecessary here.

>
>
> Here's what's left of Leon's patch:
>
> From: Leon Hwang <leon.hwang@linux.dev>
> Subject: mm/mseal: fix mseal documentation for 32-bit kernels
> Date: Wed, 15 Jul 2026 21:12:58 +0800
>
> 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>
> ---
>
>  Documentation/userspace-api/mseal.rst |   14 ++++++--------
>  init/Kconfig                          |    2 +-
>  2 files changed, 7 insertions(+), 9 deletions(-)
>
> --- a/Documentation/userspace-api/mseal.rst~mm-mseal-fix-mseal-documentation-for-32-bit-kernels
> +++ a/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
> --- a/init/Kconfig~mm-mseal-fix-mseal-documentation-for-32-bit-kernels
> +++ a/init/Kconfig
> @@ -2120,7 +2120,7 @@ config ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPIN
>  	  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
> _
>

LGTM!

Cheers, Lorenzo

Re: [PATCH 3/3] mm/mseal: remove further superfluous comments, do_mseal()

[David Hildenbrand (Arm)]

On 7/16/26 15:43, Lorenzo Stoakes (ARM) wrote:
> There's no need to abstract do_mseal() any longer so put the system call
> implementation in the system call declaration.
> 
> The comment around do_mseal() is strangely formatted, overly long and adds
> a lot of superfluous information that the code already provides, so boil it
> down to the essentials.

Lol, just what I had in mind in my comment to #2.

Nice!

Acked-by: David Hildenbrand (Arm) <david@kernel.org>


-- 
Cheers,

David

Re: [PATCH 3/3] mm/mseal: remove further superfluous comments, do_mseal()

[Lorenzo Stoakes (ARM)]

On Fri, Jul 17, 2026 at 11:50:13AM +0100, David Hildenbrand (Arm) wrote:
> On 7/16/26 15:43, Lorenzo Stoakes (ARM) wrote:
> > There's no need to abstract do_mseal() any longer so put the system call
> > implementation in the system call declaration.
> >
> > The comment around do_mseal() is strangely formatted, overly long and adds
> > a lot of superfluous information that the code already provides, so boil it
> > down to the essentials.
>
> Lol, just what I had in mind in my comment to #2.
>
> Nice!

:))

>
> Acked-by: David Hildenbrand (Arm) <david@kernel.org>

Thanks! :)

>
>
> --
> Cheers,
>
> David

Cheers, Lorenzo

Re: [PATCH 0/3] mm/mseal: further cleanups

[Lorenzo Stoakes (ARM)]

On Thu, Jul 16, 2026 at 02:43:08PM +0100, Lorenzo Stoakes (ARM) wrote:
> The mseal implementation is still rather confusing, so tighten things up a
> little.
>
> The only user of do_mseal() outside of the system call is the MMAP_PAGE_ZERO
> process personality - retain better control over how mseal is utilised by
> providing mseal_mmap_page_zero() for this instead.
>
> The comments are overly long and confusion, so cut them down so they're a lot
> clearer.

s/confusion/confusing/ :)

>
> Remove confusing mm_struct params (mseal can not be used on remote mm's) and
> wrap the actual system call logic into the system call declaration.
>
> Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
> ---
> Lorenzo Stoakes (ARM) (3):
>       mm/mseal: remove superfluous comments, fix confusion around mm
>       mm/mseal: limit scope of mseal address zero to address zero
>       mm/mseal: remove further superfluous comments, do_mseal()
>
>  fs/binfmt_elf.c    |   7 +--
>  include/linux/mm.h |   8 +--
>  mm/mseal.c         | 156 ++++++++++++++++++-----------------------------------
>  3 files changed, 56 insertions(+), 115 deletions(-)
> ---
> base-commit: 59c684a9908d2e6f7a791f7f033eae57ec2b3a61
> change-id: 20260716-mseal-fixups-131ad0939de2
>
> Cheers,
> --
> Lorenzo Stoakes (ARM) <ljs@kernel.org>
>