linux-hardening - [PATCH v9 6/7] mseal sysmap: update mseal.rst

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250305021711.3867874-7-jeffxu@google.com>
Date: Wed,  5 Mar 2025 02:17:10 +0000
From: jeffxu@...omium.org
To: akpm@...ux-foundation.org,
	keescook@...omium.org,
	jannh@...gle.com,
	torvalds@...ux-foundation.org,
	vbabka@...e.cz,
	lorenzo.stoakes@...cle.com,
	Liam.Howlett@...cle.com,
	adhemerval.zanella@...aro.org,
	oleg@...hat.com,
	avagin@...il.com,
	benjamin@...solutions.net
Cc: linux-kernel@...r.kernel.org,
	linux-hardening@...r.kernel.org,
	linux-mm@...ck.org,
	linux-kselftest@...r.kernel.org,
	jorgelo@...omium.org,
	sroettger@...gle.com,
	hch@....de,
	ojeda@...nel.org,
	thomas.weissschuh@...utronix.de,
	adobriyan@...il.com,
	johannes@...solutions.net,
	pedro.falcato@...il.com,
	hca@...ux.ibm.com,
	willy@...radead.org,
	anna-maria@...utronix.de,
	mark.rutland@....com,
	linus.walleij@...aro.org,
	Jason@...c4.com,
	deller@....de,
	rdunlap@...radead.org,
	davem@...emloft.net,
	peterx@...hat.com,
	f.fainelli@...il.com,
	gerg@...nel.org,
	dave.hansen@...ux.intel.com,
	mingo@...nel.org,
	ardb@...nel.org,
	mhocko@...e.com,
	42.hyeyoo@...il.com,
	peterz@...radead.org,
	ardb@...gle.com,
	enh@...gle.com,
	rientjes@...gle.com,
	groeck@...omium.org,
	mpe@...erman.id.au,
	aleksandr.mikhalitsyn@...onical.com,
	mike.rapoport@...il.com,
	Jeff Xu <jeffxu@...omium.org>,
	Kees Cook <kees@...nel.org>,
	"Liam R. Howlett" <Liam.Howlett@...cle.com>
Subject: [PATCH v9 6/7] mseal sysmap: update mseal.rst

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

Update memory sealing documentation to include details about system
mappings.

Signed-off-by: Jeff Xu <jeffxu@...omium.org>
Reviewed-by: Kees Cook <kees@...nel.org>
Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Reviewed-by: Liam R. Howlett <Liam.Howlett@...cle.com>
---
 Documentation/userspace-api/mseal.rst | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/Documentation/userspace-api/mseal.rst b/Documentation/userspace-api/mseal.rst
index 41102f74c5e2..56aee46a9307 100644
--- a/Documentation/userspace-api/mseal.rst
+++ b/Documentation/userspace-api/mseal.rst
@@ -130,6 +130,26 @@ Use cases
 
 - Chrome browser: protect some security sensitive data structures.
 
+- System mappings:
+  The system mappings are created by the kernel and includes 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
+  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.
+
+  The following architectures currently support this feature: x86-64 and arm64.
+
+  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
+  this config can't be enabled universally.
+
 When not to use mseal
 =====================
 Applications can apply sealing to any virtual memory region from userspace,
-- 
2.48.1.711.g2feabab25a-goog