On Wed, Mar 05, 2025 at 05:54:24AM +0000, Lorenzo Stoakes wrote:
On Wed, Mar 05, 2025 at 02:17:05AM +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 Reviewed-by: Kees Cook kees@kernel.org
Umm... I reviewed this too? :) unless you made substantial changes here (doesn't appear so), please do propagate tags for each revision :>)
Anyway, FWIW:
Reviewed-by: Lorenzo Stoakes lorenzo.stoakes@oracle.com
(you also forgot to propagate Liam's tag here)
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..7f67d8942a09 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
- 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 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 the systemmappings 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..a914a02df27e 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 64BIT
- depends on ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS
- depends on !CHECKPOINT_RESTORE
- help
Apply mseal on system mappings.The system mappings includes vdso, vvar, vvar_vclock,vectors (arm compat-mode), sigpage (arm compat-mode), uprobes.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