| Message ID | 20250224225246.3712295-2-jeffxu@google.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | mseal system mappings | expand |
On Mon, Feb 24, 2025 at 10:52:40PM +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_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 This is much better than the original thanks. > + > #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. Architectures also need to be confirmed not to require any form of VDSO relocation, which as discussed in previous series some arches appear to need to do. I'd mention that here. > + > + 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. Let's be specific here, 'etc.' could mean _anything_. Also you aren't sealing most of this, let's just list what you are _actually_ sealing here. Which is AFAIK VDSO only? You can update this later as time goes on if/when you expand this. > + > + 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. Thanks for putting this here, appreciate it! Could we tweak this though? I'd like to make it crystal clear, so I don't think 'note' sufficies and this sounds a little too vague. I think 'warning' is more appropriate here since you're breaking things for people who might be unaware. And we need to say this -breaks- programs: 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 and rr. I think this is critical. > + > + 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 >
* jeffxu@chromium.org <jeffxu@chromium.org> [250224 17:52]: > 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 I think we said ARCH_SUPPORTS_ for software features in v5 of the series [1]. Can we also make this change please? ... Thanks, Liam [1]. https://lore.kernel.org/all/202502131142.F5EE115C3A@keescook/
On Tue, Feb 25, 2025 at 10:22:56AM -0500, Liam R. Howlett wrote: > * jeffxu@chromium.org <jeffxu@chromium.org> [250224 17:52]: > > 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 > > I think we said ARCH_SUPPORTS_ for software features in v5 of the series > [1]. Can we also make this change please? Jeff - I'm going to risk sounding like a typical, grumpy, kernel maintainer here (sorry! :P) but please, please do ensure that you address all prior feedback. It may be worth even, when things settle down here, putting together a list of things you intend to address in the next round and double-check you've covered everything off. Because obviously when this happens once it's probably an oversight, but it seems you've failed to address at least 4 separate things requested of you here. It's obivously s going to make this a faaar more drawn out process for al linvolved. Again, to be clear, as to allay LWN articles about 'Stoakes urging caution' or what not and related drama - my intent in saying this is purely that _I want this series to land_. So I say it merely to help expedite this! :) Cheers, Lorenzo > > ... > > Thanks, > Liam > > [1]. https://lore.kernel.org/all/202502131142.F5EE115C3A@keescook/
On Tue, Feb 25, 2025 at 7:23 AM Liam R. Howlett <Liam.Howlett@oracle.com> wrote: > > * jeffxu@chromium.org <jeffxu@chromium.org> [250224 17:52]: > > 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 > > I think we said ARCH_SUPPORTS_ for software features in v5 of the series > [1]. Can we also make this change please? > Sure. > ... > > Thanks, > Liam > > [1]. https://lore.kernel.org/all/202502131142.F5EE115C3A@keescook/
On Mon, Feb 24, 2025 at 10:05 PM Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote: > > +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. > > Architectures also need to be confirmed not to require any form of VDSO > relocation, which as discussed in previous series some arches appear to > need to do. I'd mention that here. > This might need clarification, the system mapping includes vdso, right ? Why the focus on vdso ? The sentence "... it doesn't unmap/remap system mappings during the lifetime of the process." already cover what you want here, I think. > > + > > + 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. > > Let's be specific here, 'etc.' could mean _anything_. Also you aren't > sealing most of this, let's just list what you are _actually_ sealing > here. Which is AFAIK VDSO only? > I will remove "etc" and list all the mappings. Those mappings are: vdso, vvar, vvar_vclock, vectors (arm compact-mode) and sigpage (arm compact-mode), uprobe. We seal all system mappings that x86-64 and arm64 have. > You can update this later as time goes on if/when you expand this. > > > + > > + 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. > > Thanks for putting this here, appreciate it! > > Could we tweak this though? I'd like to make it crystal clear, so I don't > think 'note' sufficies and this sounds a little too vague. > > I think 'warning' is more appropriate here since you're breaking things for > people who might be unaware. And we need to say this -breaks- programs: > > 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 and rr. > > I think this is critical. > Sure.
On Tue, Feb 25, 2025 at 05:33:24PM -0800, Jeff Xu wrote: > On Mon, Feb 24, 2025 at 10:05 PM Lorenzo Stoakes > <lorenzo.stoakes@oracle.com> wrote: > > > +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. > > > > Architectures also need to be confirmed not to require any form of VDSO > > relocation, which as discussed in previous series some arches appear to > > need to do. I'd mention that here. > > > This might need clarification, the system mapping includes vdso, right > ? Why the focus on vdso ? My mistake, I thought scope was more limited than this when I first looked. Please disregard the focus on VDSO here... :) > > The sentence "... it doesn't unmap/remap system mappings during the > lifetime of the process." already cover what you want here, I think. > Right, I guess it just doesn't quite _emphasise_ it enough for me. Something like the below would really help bring that out: The existing of this flag for an architecture implies that it does not require the remapping of these system mappings during process lifetime, so sealing these mappings is safe from a kernel perspective. > > > > + > > > + 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. > > > > Let's be specific here, 'etc.' could mean _anything_. Also you aren't > > sealing most of this, let's just list what you are _actually_ sealing > > here. Which is AFAIK VDSO only? > > > I will remove "etc" and list all the mappings. > > Those mappings are: > vdso, vvar, vvar_vclock, vectors (arm compact-mode) and sigpage (arm > compact-mode), uprobe. > > We seal all system mappings that x86-64 and arm64 have. Perfect! > > > You can update this later as time goes on if/when you expand this. > > > > > + > > > + 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. > > > > Thanks for putting this here, appreciate it! > > > > Could we tweak this though? I'd like to make it crystal clear, so I don't > > think 'note' sufficies and this sounds a little too vague. > > > > I think 'warning' is more appropriate here since you're breaking things for > > people who might be unaware. And we need to say this -breaks- programs: > > > > 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 and rr. > > > > I think this is critical. > > > Sure. Perfect, thank you! Much appreciated.
On Tue, Feb 25, 2025 at 10:04 PM Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote: > > On Tue, Feb 25, 2025 at 05:33:24PM -0800, Jeff Xu wrote: > > On Mon, Feb 24, 2025 at 10:05 PM Lorenzo Stoakes > > <lorenzo.stoakes@oracle.com> wrote: > > > > +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. > > > > > > Architectures also need to be confirmed not to require any form of VDSO > > > relocation, which as discussed in previous series some arches appear to > > > need to do. I'd mention that here. > > > > > This might need clarification, the system mapping includes vdso, right > > ? Why the focus on vdso ? > > My mistake, I thought scope was more limited than this when I first > looked. Please disregard the focus on VDSO here... :) > > > > > The sentence "... it doesn't unmap/remap system mappings during the > > lifetime of the process." already cover what you want here, I think. > > > > Right, I guess it just doesn't quite _emphasise_ it enough for me. Something > like the below would really help bring that out: > > The existing of this flag for an architecture implies that it does not > require the remapping of these system mappings during process lifetime, > so sealing these mappings is safe from a kernel perspective. > I'm not sure I get the difference, but I can add it, is below OK ? 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. The existence of this flag for an architecture implies that it does not require the remapping of these system mappings during process lifetime, so sealing these mappings is safe from a kernel perspective. After the architecture enables this, a distribution can set CONFIG_MSEAL_SYSTEM_MAPPING to manage access to the feature. Thanks -Jeff
On Thu, Feb 27, 2025 at 04:04:03PM -0800, Jeff Xu wrote: > On Tue, Feb 25, 2025 at 10:04 PM Lorenzo Stoakes > <lorenzo.stoakes@oracle.com> wrote: > > > > On Tue, Feb 25, 2025 at 05:33:24PM -0800, Jeff Xu wrote: > > > On Mon, Feb 24, 2025 at 10:05 PM Lorenzo Stoakes > > > <lorenzo.stoakes@oracle.com> wrote: > > > > > +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. > > > > > > > > Architectures also need to be confirmed not to require any form of VDSO > > > > relocation, which as discussed in previous series some arches appear to > > > > need to do. I'd mention that here. > > > > > > > This might need clarification, the system mapping includes vdso, right > > > ? Why the focus on vdso ? > > > > My mistake, I thought scope was more limited than this when I first > > looked. Please disregard the focus on VDSO here... :) > > > > > > > > The sentence "... it doesn't unmap/remap system mappings during the > > > lifetime of the process." already cover what you want here, I think. > > > > > > > Right, I guess it just doesn't quite _emphasise_ it enough for me. Something > > like the below would really help bring that out: > > > > The existing of this flag for an architecture implies that it does not > > require the remapping of these system mappings during process lifetime, > > so sealing these mappings is safe from a kernel perspective. > > > I'm not sure I get the difference, but I can add it, is below OK ? > > 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. The existence of this flag for an architecture > implies that it does not require the remapping of these system > mappings during process lifetime, so sealing these mappings is > safe from a kernel perspective. After the architecture enables this, > a distribution can set CONFIG_MSEAL_SYSTEM_MAPPING to > manage access to the feature. Sounds great, cheers! > > Thanks > -Jeff
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