Message-ID: <cover.1753431105.git.lorenzo.stoakes@oracle.com>
Date: Fri, 25 Jul 2025 09:29:40 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: "Liam R . Howlett" <Liam.Howlett@...cle.com>,
        David Hildenbrand <david@...hat.com>, Vlastimil Babka <vbabka@...e.cz>,
        Jann Horn <jannh@...gle.com>, Pedro Falcato <pfalcato@...e.de>,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        Jeff Xu <jeffxu@...omium.org>, Kees Cook <kees@...nel.org>
Subject: [PATCH v4 0/5] mseal cleanups

Perform a number of cleanups to the mseal logic. Firstly, VM_SEALED is
treated differently from every other VMA flag, it really doesn't make sense
to do this, so we start by making this consistent with everything else.

Next we place the madvise logic where it belongs - in mm/madvise.c. It
really makes no sense to abstract this elsewhere. In doing so, we go to
great lengths to explain very clearly the previously very confusing logic
as to what sealed mappings are impacted here.

In doing so, we retain existing logic regarding treatment of madvise()
discard operations for a sealed, read-only MAP_PRIVATE file-backed
mapping. This is something we likely need to revisit.

We then abstract out and explain the 'are there are any gaps in this range
in the mm?' check being performed as a prerequisite to mseal being
performed.

Finally, we simplify the actual mseal logic which is really quite
straightforward.

No functional change is intended.


NOTE - this replaces the previous "mseal cleanups, fixup MAP_PRIVATE
file-backed case" series (linked below under v3), I renamed to 'mseal
cleaups' only as now we do not adjust MAP_PRIVATE behaviour.

v4:
* Propagated tags, thanks Jeff!
* Remove the change in semantics for MAP_PRIVATE, file-backed, mseal()'d
  mappings, as it turns out there is more complexity than expected
  here. Let's stick to a straight refactoring for now. Based on discussions
  with Jeff, Kees and David.
* Reinstated comment previously present in check_mm_seal() regarding
  expectations of input range in range_contains_unmapped() where this makes
  sense to locate, removing the redundant 'map is sealable' step, as per
  Jeff.

v3:
* Propagated more tags, thanks everyone!
* Updated 5/5 to assign curr_start in a smarter way as per Liam. Adjust
  code to more sensibly handle already-sealed case at the same time.
* Updated 4/5 to not move range_contains_unmapped() for better diff.
* Renamed can_modify_vma() to vma_is_sealed() and inverted the logic - this
  is far clearer than the nebulous 'can modify VMA'.
https://lore.kernel.org/all/cover.1752687069.git.lorenzo.stoakes@oracle.com/

v2:
* Propagated tags, thanks everyone!
* Updated can_madvise_modify() to a more logical order re: the checks
  performed, as per David.
* Replaced vma_is_anonymous() check (which was, in the original code, a
  vma->vm_file or vma->vm_ops check) with a vma->vm_flags & VM_SHARED
  check - to explicitly check for shared mappings vs private to preclude
  MAP_PRIVATE-mapping file-baked mappings, as per David.
* Made range_contains_unmapped() static and placed in mm/mseal.c to avoid
  encouraging any other internal users towards this rather silly pattern,
  as per Pedro and Liam.
https://lore.kernel.org/all/cover.1752586090.git.lorenzo.stoakes@oracle.com/

v1:
https://lore.kernel.org/all/cover.1752497324.git.lorenzo.stoakes@oracle.com/


Lorenzo Stoakes (5):
  mm/mseal: always define VM_SEALED
  mm/mseal: update madvise() logic
  mm/mseal: small cleanups
  mm/mseal: simplify and rename VMA gap check
  mm/mseal: rework mseal apply logic

 include/linux/mm.h               |   6 +-
 mm/madvise.c                     |  71 +++++++++++++-
 mm/mprotect.c                    |   2 +-
 mm/mremap.c                      |   2 +-
 mm/mseal.c                       | 160 +++++++------------------------
 mm/vma.c                         |   4 +-
 mm/vma.h                         |  27 +-----
 tools/testing/vma/vma_internal.h |   6 +-
 8 files changed, 119 insertions(+), 159 deletions(-)

--
2.50.1

Powered by blists - more mailing lists