| 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
| ||
|
Message-ID: <9abd68d9-3e6d-46a0-b92c-5aee0a90abf3@lucifer.local>
Date: Tue, 25 Feb 2025 06:05:21 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: jeffxu@...omium.org
Cc: akpm@...ux-foundation.org, keescook@...omium.org, jannh@...gle.com,
torvalds@...ux-foundation.org, vbabka@...e.cz, Liam.Howlett@...cle.com,
adhemerval.zanella@...aro.org, oleg@...hat.com, avagin@...il.com,
benjamin@...solutions.net, linux-kernel@...r.kernel.org,
linux-hardening@...r.kernel.org, linux-mm@...ck.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
Subject: Re: [PATCH v7 1/7] mseal, system mappings: kernel config and header
change
On Mon, Feb 24, 2025 at 10:52:40PM +0000, jeffxu@...omium.org wrote:
> From: Jeff Xu <jeffxu@...omium.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@...omium.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
>
Powered by blists - more mailing lists