On Mon, Mar 3, 2025 at 8:37 AM Kees Cook kees@kernel.org wrote:
On Mon, Mar 03, 2025 at 05:09:15AM +0000, jeffxu@chromium.org wrote:
From: Jeff Xu jeffxu@chromium.org
Provide infrastructure to mseal system mappings. Establish two kernel configs (CONFIG_MSEAL_SYSTEM_MAPPINGS, ARCH_SUPPORTS_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 | 22 ++++++++++++++++++++++ security/Kconfig | 21 +++++++++++++++++++++ 3 files changed, 53 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..c90dd8778993 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -1882,6 +1882,28 @@ config ARCH_HAS_MEMBARRIER_CALLBACKS config ARCH_HAS_MEMBARRIER_SYNC_CORE bool
+config ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS
boolhelpControl 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 theirspecial mappings calls to include the sealing flag and confirmthat it doesn't unmap/remap system mappings during the lifetime of the process. The existence of this flag for an architectureimplies that it does not require the remapping of thest systemtypo nit: "the" instead of "thest"
mappings during process lifetime, so sealing these mappings is safefrom a kernel perspective.After the architecture enables this, a distribution can setCONFIG_MSEAL_SYSTEM_MAPPING to manage access to the feature.For complete descriptions of memory sealing, please seeDocumentation/userspace-api/mseal.rstconfig HAVE_PERF_EVENTS bool help diff --git a/security/Kconfig b/security/Kconfig index f10dbf15c294..5311f4a6786c 100644 --- a/security/Kconfig +++ b/security/Kconfig @@ -51,6 +51,27 @@ config PROC_MEM_NO_FORCE
endchoice
+config MSEAL_SYSTEM_MAPPINGS
bool "mseal system mappings"depends on 64BITdepends on ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGSdepends on !CHECKPOINT_RESTOREhelpApply mseal on system mappings.The system mappings includes vdso, vvar, vvar_vclock,vectors (arm compact-mode), sigpage (arm compact-mode), uprobes.typo nits: "compat" instead of "compact".
Got it, I will change everywhere for this (mseal.rst, coverletter)
A 64-bit kernel is required for the memory sealing feature.No specific hardware features from the CPU are needed.WARNING: This feature breaks programs which rely on relocatingor unmapping system mappings. Known broken software at the timeof writing includes CHECKPOINT_RESTORE, UML, gVisor, rr. Thereforethis config can't be enabled universally.For complete descriptions of memory sealing, please seeDocumentation/userspace-api/mseal.rstconfig SECURITY bool "Enable different security models" depends on SYSFS -- 2.48.1.711.g2feabab25a-goog
Perhaps akpm can fix these up directly instead of a v9 spin?
V9 is relatively easy for me. I probably need a good version for backporting to chromeOS/Android.
If all goes well, I'll follow up with a V10 based on Thomas Weißschuh's vdso refactor branch [1] [2].
[1] https://lore.kernel.org/all/CABi2SkXwaJ=s3XqHKu1aFVfcacgxpQ5Ji1_BqaN+ch2i_Rn... [2] https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?h=timers/vd...
But otherwise, yes, reads well to me:
Reviewed-by: Kees Cook kees@kernel.org
-- Kees Cook