From: jeffxu@chromium.org
To: akpm@linux-foundation.org, keescook@chromium.org,
jannh@google.com, torvalds@linux-foundation.org, vbabka@suse.cz,
lorenzo.stoakes@oracle.com, Liam.Howlett@Oracle.com,
adhemerval.zanella@linaro.org, oleg@redhat.com, avagin@gmail.com,
benjamin@sipsolutions.net
Cc: linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org,
linux-mm@kvack.org, jorgelo@chromium.org, sroettger@google.com,
hch@lst.de, ojeda@kernel.org, thomas.weissschuh@linutronix.de,
adobriyan@gmail.com, johannes@sipsolutions.net,
pedro.falcato@gmail.com, hca@linux.ibm.com, willy@infradead.org,
anna-maria@linutronix.de, mark.rutland@arm.com,
linus.walleij@linaro.org, Jason@zx2c4.com, deller@gmx.de,
rdunlap@infradead.org, davem@davemloft.net, peterx@redhat.com,
f.fainelli@gmail.com, gerg@kernel.org,
dave.hansen@linux.intel.com, mingo@kernel.org, ardb@kernel.org,
mhocko@suse.com, 42.hyeyoo@gmail.com, peterz@infradead.org,
ardb@google.com, enh@google.com, rientjes@google.com,
groeck@chromium.org, mpe@ellerman.id.au,
aleksandr.mikhalitsyn@canonical.com, mike.rapoport@gmail.com,
Jeff Xu <jeffxu@chromium.org>
Subject: [PATCH v7 1/7] mseal, system mappings: kernel config and header change
Date: Mon, 24 Feb 2025 22:52:40 +0000 [thread overview]
Message-ID: <20250224225246.3712295-2-jeffxu@google.com> (raw)
In-Reply-To: <20250224225246.3712295-1-jeffxu@google.com>
From: Jeff Xu <jeffxu@chromium.org>
Provide infrastructure to mseal system mappings. Establish
two kernel configs (CONFIG_MSEAL_SYSTEM_MAPPINGS,
ARCH_HAS_MSEAL_SYSTEM_MAPPINGS) and VM_SEALED_SYSMAP
macro for future patches.
Signed-off-by: Jeff Xu <jeffxu@chromium.org>
---
include/linux/mm.h | 10 ++++++++++
init/Kconfig | 18 ++++++++++++++++++
security/Kconfig | 18 ++++++++++++++++++
3 files changed, 46 insertions(+)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 7b1068ddcbb7..8b800941678d 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -4155,4 +4155,14 @@ int arch_get_shadow_stack_status(struct task_struct *t, unsigned long __user *st
int arch_set_shadow_stack_status(struct task_struct *t, unsigned long status);
int arch_lock_shadow_stack_status(struct task_struct *t, unsigned long status);
+
+/*
+ * mseal of userspace process's system mappings.
+ */
+#ifdef CONFIG_MSEAL_SYSTEM_MAPPINGS
+#define VM_SEALED_SYSMAP VM_SEALED
+#else
+#define VM_SEALED_SYSMAP VM_NONE
+#endif
+
#endif /* _LINUX_MM_H */
diff --git a/init/Kconfig b/init/Kconfig
index d0d021b3fa3b..07435e33f965 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1882,6 +1882,24 @@ config ARCH_HAS_MEMBARRIER_CALLBACKS
config ARCH_HAS_MEMBARRIER_SYNC_CORE
bool
+config ARCH_HAS_MSEAL_SYSTEM_MAPPINGS
+ bool
+ help
+ Control MSEAL_SYSTEM_MAPPINGS access based on architecture.
+
+ A 64-bit kernel is required for the memory sealing feature.
+ No specific hardware features from the CPU are needed.
+
+ To enable this feature, the architecture needs to update their
+ special mappings calls to include the sealing flag and confirm
+ that it doesn't unmap/remap system mappings during the life
+ time of the process. After the architecture enables this, a
+ distribution can set CONFIG_MSEAL_SYSTEM_MAPPING to manage access
+ to the feature.
+
+ For complete descriptions of memory sealing, please see
+ Documentation/userspace-api/mseal.rst
+
config HAVE_PERF_EVENTS
bool
help
diff --git a/security/Kconfig b/security/Kconfig
index f10dbf15c294..15a86a952910 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -51,6 +51,24 @@ config PROC_MEM_NO_FORCE
endchoice
+config MSEAL_SYSTEM_MAPPINGS
+ bool "mseal system mappings"
+ depends on 64BIT
+ depends on ARCH_HAS_MSEAL_SYSTEM_MAPPINGS
+ depends on !CHECKPOINT_RESTORE
+ help
+ Seal system mappings such as vdso, vvar, sigpage, uprobes, etc.
+
+ A 64-bit kernel is required for the memory sealing feature.
+ No specific hardware features from the CPU are needed.
+
+ Note: CHECKPOINT_RESTORE, UML, gVisor, rr are known to relocate or
+ unmap system mapping, therefore this config can't be enabled
+ universally.
+
+ For complete descriptions of memory sealing, please see
+ Documentation/userspace-api/mseal.rst
+
config SECURITY
bool "Enable different security models"
depends on SYSFS
--
2.48.1.658.g4767266eb4-goog
next prev parent reply other threads:[~2025-02-24 22:52 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-24 22:52 [PATCH v7 0/7] mseal system mappings jeffxu
2025-02-24 22:52 ` jeffxu [this message]
2025-02-25 6:05 ` [PATCH v7 1/7] mseal, system mappings: kernel config and header change Lorenzo Stoakes
2025-02-26 1:33 ` Jeff Xu
2025-02-26 6:04 ` Lorenzo Stoakes
2025-02-28 0:04 ` Jeff Xu
2025-02-28 10:32 ` Lorenzo Stoakes
2025-02-25 15:22 ` Liam R. Howlett
2025-02-25 15:37 ` Lorenzo Stoakes
2025-02-26 0:04 ` Jeff Xu
2025-02-24 22:52 ` [PATCH v7 2/7] selftests: x86: test_mremap_vdso: skip if vdso is msealed jeffxu
2025-02-25 6:15 ` Lorenzo Stoakes
2025-02-25 22:37 ` Jeff Xu
2025-02-26 5:58 ` Lorenzo Stoakes
2025-02-24 22:52 ` [PATCH v7 3/7] mseal, system mappings: enable x86-64 jeffxu
2025-02-25 1:03 ` Kees Cook
2025-02-26 0:21 ` Jeff Xu
2025-02-25 8:08 ` Thomas Weißschuh
2025-02-26 0:48 ` Jeff Xu
2025-02-26 7:35 ` Thomas Weißschuh
2025-02-27 21:44 ` Jeff Xu
2025-02-24 22:52 ` [PATCH v7 4/7] mseal, system mappings: enable arm64 jeffxu
2025-02-25 6:20 ` Lorenzo Stoakes
2025-02-25 22:26 ` Jeff Xu
2025-02-26 5:25 ` Lorenzo Stoakes
2025-02-26 17:11 ` Liam R. Howlett
2025-02-26 17:17 ` Jeff Xu
2025-02-26 17:43 ` Lorenzo Stoakes
2025-02-26 18:14 ` Lorenzo Stoakes
2025-02-28 0:48 ` Jeff Xu
2025-02-28 10:31 ` Lorenzo Stoakes
2025-02-24 22:52 ` [PATCH v7 5/7] mseal, system mappings: enable uml architecture jeffxu
2025-02-25 6:22 ` Lorenzo Stoakes
2025-02-25 8:45 ` Berg, Benjamin
2025-02-25 10:37 ` Lorenzo Stoakes
2025-02-25 12:24 ` Benjamin Berg
2025-02-25 13:41 ` Lorenzo Stoakes
2025-02-25 13:59 ` Johannes Berg
2025-02-25 15:06 ` Kees Cook
2025-02-25 15:31 ` Lorenzo Stoakes
2025-02-25 18:38 ` Kees Cook
2025-02-26 0:00 ` Jeff Xu
2025-02-24 22:52 ` [PATCH v7 6/7] mseal, system mappings: uprobe mapping jeffxu
2025-02-25 6:24 ` Lorenzo Stoakes
2025-02-26 0:06 ` Jeff Xu
2025-02-26 5:57 ` Lorenzo Stoakes
2025-02-26 16:26 ` Oleg Nesterov
2025-02-26 16:33 ` Oleg Nesterov
2025-02-26 16:45 ` Lorenzo Stoakes
2025-02-26 18:01 ` Oleg Nesterov
2025-02-26 18:06 ` Lorenzo Stoakes
2025-02-26 18:19 ` Liam R. Howlett
2025-02-26 18:20 ` Oleg Nesterov
2025-02-26 18:25 ` Lorenzo Stoakes
2025-02-27 23:38 ` Jeff Xu
2025-02-28 10:39 ` Lorenzo Stoakes
2025-02-27 21:48 ` Jeff Xu
2025-02-24 22:52 ` [PATCH v7 7/7] mseal, system mappings: update mseal.rst jeffxu
2025-02-24 23:03 ` [PATCH v7 0/7] mseal system mappings Pedro Falcato
2025-02-24 23:07 ` Jeff Xu
2025-02-25 6:09 ` Lorenzo Stoakes
2025-02-25 10:32 ` Lorenzo Stoakes
2025-02-26 0:17 ` Jeff Xu
2025-02-26 6:00 ` Lorenzo Stoakes
2025-02-27 23:43 ` Jeff Xu
2025-02-28 10:32 ` Lorenzo Stoakes
2025-02-25 15:18 ` Lorenzo Stoakes
2025-02-26 0:12 ` Jeff Xu
2025-02-26 5:42 ` your mail Lorenzo Stoakes
2025-02-28 0:55 ` Jeff Xu
2025-02-28 9:35 ` Lorenzo Stoakes
2025-02-28 17:24 ` Jeff Xu
2025-02-28 17:30 ` Lorenzo Stoakes
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=20250224225246.3712295-2-jeffxu@google.com \
--to=jeffxu@chromium.org \
--cc=42.hyeyoo@gmail.com \
--cc=Jason@zx2c4.com \
--cc=Liam.Howlett@Oracle.com \
--cc=adhemerval.zanella@linaro.org \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=aleksandr.mikhalitsyn@canonical.com \
--cc=anna-maria@linutronix.de \
--cc=ardb@google.com \
--cc=ardb@kernel.org \
--cc=avagin@gmail.com \
--cc=benjamin@sipsolutions.net \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=deller@gmx.de \
--cc=enh@google.com \
--cc=f.fainelli@gmail.com \
--cc=gerg@kernel.org \
--cc=groeck@chromium.org \
--cc=hca@linux.ibm.com \
--cc=hch@lst.de \
--cc=jannh@google.com \
--cc=johannes@sipsolutions.net \
--cc=jorgelo@chromium.org \
--cc=keescook@chromium.org \
--cc=linus.walleij@linaro.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mark.rutland@arm.com \
--cc=mhocko@suse.com \
--cc=mike.rapoport@gmail.com \
--cc=mingo@kernel.org \
--cc=mpe@ellerman.id.au \
--cc=ojeda@kernel.org \
--cc=oleg@redhat.com \
--cc=pedro.falcato@gmail.com \
--cc=peterx@redhat.com \
--cc=peterz@infradead.org \
--cc=rdunlap@infradead.org \
--cc=rientjes@google.com \
--cc=sroettger@google.com \
--cc=thomas.weissschuh@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.