From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: Andrew Morton <akpm@linux-foundation.org>,
"Liam R. Howlett" <liam@infradead.org>,
Vlastimil Babka <vbabka@kernel.org>,
Jann Horn <jannh@google.com>, Pedro Falcato <pfalcato@suse.de>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
Kees Cook <kees@kernel.org>,
David Hildenbrand <david@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org,
"Lorenzo Stoakes (ARM)" <ljs@kernel.org>
Subject: [PATCH 3/3] mm/mseal: remove further superfluous comments, do_mseal()
Date: Thu, 16 Jul 2026 14:43:11 +0100 [thread overview]
Message-ID: <20260716-mseal-fixups-v1-3-3a9609bf041b@kernel.org> (raw)
In-Reply-To: <20260716-mseal-fixups-v1-0-3a9609bf041b@kernel.org>
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
next prev parent reply other threads:[~2026-07-16 13:43 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-16 13:43 [PATCH 0/3] mm/mseal: further cleanups Lorenzo Stoakes (ARM)
2026-07-16 13:43 ` [PATCH 1/3] mm/mseal: remove superfluous comments, fix confusion around mm Lorenzo Stoakes (ARM)
2026-07-16 15:00 ` Pedro Falcato
2026-07-17 10:33 ` David Hildenbrand (Arm)
2026-07-17 10:44 ` Lorenzo Stoakes (ARM)
2026-07-16 13:43 ` [PATCH 2/3] mm/mseal: limit scope of mseal address zero to address zero Lorenzo Stoakes (ARM)
2026-07-16 15:06 ` Pedro Falcato
2026-07-16 15:38 ` Lorenzo Stoakes (ARM)
2026-07-17 10:41 ` David Hildenbrand (Arm)
2026-07-17 10:51 ` Lorenzo Stoakes (ARM)
2026-07-17 10:46 ` David Hildenbrand (Arm)
2026-07-17 10:49 ` David Hildenbrand (Arm)
2026-07-17 10:52 ` Lorenzo Stoakes (ARM)
2026-07-16 13:43 ` Lorenzo Stoakes (ARM) [this message]
2026-07-16 15:09 ` [PATCH 3/3] mm/mseal: remove further superfluous comments, do_mseal() Pedro Falcato
2026-07-16 15:13 ` Lorenzo Stoakes (ARM)
2026-07-17 0:33 ` Andrew Morton
2026-07-17 11:06 ` Lorenzo Stoakes (ARM)
2026-07-17 10:50 ` David Hildenbrand (Arm)
2026-07-17 10:55 ` Lorenzo Stoakes (ARM)
2026-07-16 13:48 ` [PATCH 0/3] mm/mseal: further cleanups Lorenzo Stoakes (ARM)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260716-mseal-fixups-v1-3-3a9609bf041b@kernel.org \
--to=ljs@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=david@kernel.org \
--cc=jack@suse.cz \
--cc=jannh@google.com \
--cc=kees@kernel.org \
--cc=liam@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=pfalcato@suse.de \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox