linux-kernel - [RFC PATCH v1 0/2] mseal: allow noop mprotect

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250312002117.2556240-1-jeffxu@google.com>
Date: Wed, 12 Mar 2025 00:21:15 +0000
From: jeffxu@...omium.org
To: akpm@...ux-foundation.org,
	vbabka@...e.cz,
	lorenzo.stoakes@...cle.com,
	Liam.Howlett@...cle.com,
	broonie@...nel.org,
	skhan@...uxfoundation.org
Cc: linux-kernel@...r.kernel.org,
	linux-hardening@...r.kernel.org,
	linux-kselftest@...r.kernel.org,
	linux-mm@...ck.org,
	jorgelo@...omium.org,
	keescook@...omium.org,
	pedro.falcato@...il.com,
	rdunlap@...radead.org,
	jannh@...gle.com,
	Jeff Xu <jeffxu@...omium.org>
Subject: [RFC PATCH v1 0/2] mseal: allow noop mprotect

From: Jeff Xu <jeffxu@...omium.org>

Initially, when mseal was introduced in 6.10, semantically, when a VMA
within the specified address range is sealed, the mprotect will be rejected,
leaving all of VMA unmodified. However, adding an extra loop to check the mseal
flag for every VMA slows things down a bit, therefore in 6.12, this issue was
solved by removing can_modify_mm and checking each VMA’s mseal flag directly
without an extra loop [1]. This is a semantic change, i.e. partial update is
allowed, VMAs can be updated until a sealed VMA is found.

The new semantic also means, we could allow mprotect on a sealed VMA if the new
attribute of VMA remains the same as the old one. Relaxing this avoids unnecessary
impacts for applications that want to seal a particular mapping. Doing this also
has no security impact.

The mseal_test is also modified by this patch to adapt to the new
semantic. Please note, mseal_test is currently undergoing refactoring,
and eventually will be replaced with a new memory sealing selftest.
In this patch, I only make a minimum change to make it pass. I considered
adding a new testcase in mseal_test to cover this new behavior, however, the
existing mseal_test is using wrong patterns and won’t pass the review.
Such a new test is better to be added in the new refactored memory sealing tests.
The refactoring is currently pending review [2].

[1] https://lore.kernel.org/all/20240817-mseal-depessimize-v3-0-d8d2e037df30@gmail.com/
[2] https://lore.kernel.org/all/20241211053311.245636-1-jeffxu@google.com/

Jeff Xu (2):
  selftests/mm: mseal_test: avoid using no-op mprotect
  mseal: allow noop mprotect

 mm/mprotect.c                           | 6 +++---
 tools/testing/selftests/mm/mseal_test.c | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

-- 
2.49.0.rc0.332.g42c0ae87b1-goog