Documentation/userspace-api/mseal.rst | 2 +- arch/loongarch/Kconfig | 1 + arch/loongarch/kernel/vdso.c | 4 +++- 3 files changed, 5 insertions(+), 2 deletions(-)
Provide support for CONFIG_MSEAL_SYSTEM_MAPPINGS on LoongArch,
covering the vdso.
Tested-by: Yuli Wang <wangyuli@uniontech.com>
Signed-off-by: Yuli Wang <wangyuli@uniontech.com>
---
Documentation/userspace-api/mseal.rst | 2 +-
arch/loongarch/Kconfig | 1 +
arch/loongarch/kernel/vdso.c | 4 +++-
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/userspace-api/mseal.rst b/Documentation/userspace-api/mseal.rst
index 1dabfc29be0d..ef733f69003d 100644
--- a/Documentation/userspace-api/mseal.rst
+++ b/Documentation/userspace-api/mseal.rst
@@ -144,7 +144,7 @@ Use cases
architecture.
The following architectures currently support this feature: x86-64, arm64,
- and s390.
+ loongarch and s390.
WARNING: This feature breaks programs which rely on relocating
or unmapping system mappings. Known broken software at the time
diff --git a/arch/loongarch/Kconfig b/arch/loongarch/Kconfig
index 067c0b994648..54ed5b59a690 100644
--- a/arch/loongarch/Kconfig
+++ b/arch/loongarch/Kconfig
@@ -69,6 +69,7 @@ config LOONGARCH
select ARCH_SUPPORTS_INT128 if CC_HAS_INT128
select ARCH_SUPPORTS_LTO_CLANG
select ARCH_SUPPORTS_LTO_CLANG_THIN
+ select ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS
select ARCH_SUPPORTS_NUMA_BALANCING
select ARCH_SUPPORTS_RT
select ARCH_USE_BUILTIN_BSWAP
diff --git a/arch/loongarch/kernel/vdso.c b/arch/loongarch/kernel/vdso.c
index 10cf1608c7b3..7b888d9085a0 100644
--- a/arch/loongarch/kernel/vdso.c
+++ b/arch/loongarch/kernel/vdso.c
@@ -105,7 +105,9 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
vdso_addr = data_addr + VVAR_SIZE;
vma = _install_special_mapping(mm, vdso_addr, info->size,
- VM_READ | VM_EXEC | VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC,
+ VM_READ | VM_EXEC |
+ VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC |
+ VM_SEALED_SYSMAP,
&info->code_mapping);
if (IS_ERR(vma)) {
ret = PTR_ERR(vma);
--
2.49.0On Tue, Apr 15, 2025 at 09:49:33PM +0800, WangYuli wrote:
> Provide support for CONFIG_MSEAL_SYSTEM_MAPPINGS on LoongArch,
> covering the vdso.
>
> Tested-by: Yuli Wang <wangyuli@uniontech.com>
> Signed-off-by: Yuli Wang <wangyuli@uniontech.com>
I'm sure it's fine, but I am yet to encounter somebody enabling this for an
arch and saying 'I have checked to ensure we in no way rely on remapping
the VDSO, VVAR or any other special mapping'.
Because if you haven't, doing this breaks your arch.
I hate to sound like a grumpy maintainer, but could I just ask to check
whether you have, indeed, confirmed this? :)
If so then all good.
I also think we have a table somewhere in a doc that needs updating then?
Jeff, can you confirm?
Thanks!
> ---
> Documentation/userspace-api/mseal.rst | 2 +-
> arch/loongarch/Kconfig | 1 +
> arch/loongarch/kernel/vdso.c | 4 +++-
> 3 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/userspace-api/mseal.rst b/Documentation/userspace-api/mseal.rst
> index 1dabfc29be0d..ef733f69003d 100644
> --- a/Documentation/userspace-api/mseal.rst
> +++ b/Documentation/userspace-api/mseal.rst
> @@ -144,7 +144,7 @@ Use cases
> architecture.
>
> The following architectures currently support this feature: x86-64, arm64,
> - and s390.
> + loongarch and s390.
>
> WARNING: This feature breaks programs which rely on relocating
> or unmapping system mappings. Known broken software at the time
> diff --git a/arch/loongarch/Kconfig b/arch/loongarch/Kconfig
> index 067c0b994648..54ed5b59a690 100644
> --- a/arch/loongarch/Kconfig
> +++ b/arch/loongarch/Kconfig
> @@ -69,6 +69,7 @@ config LOONGARCH
> select ARCH_SUPPORTS_INT128 if CC_HAS_INT128
> select ARCH_SUPPORTS_LTO_CLANG
> select ARCH_SUPPORTS_LTO_CLANG_THIN
> + select ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS
> select ARCH_SUPPORTS_NUMA_BALANCING
> select ARCH_SUPPORTS_RT
> select ARCH_USE_BUILTIN_BSWAP
> diff --git a/arch/loongarch/kernel/vdso.c b/arch/loongarch/kernel/vdso.c
> index 10cf1608c7b3..7b888d9085a0 100644
> --- a/arch/loongarch/kernel/vdso.c
> +++ b/arch/loongarch/kernel/vdso.c
> @@ -105,7 +105,9 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
>
> vdso_addr = data_addr + VVAR_SIZE;
> vma = _install_special_mapping(mm, vdso_addr, info->size,
> - VM_READ | VM_EXEC | VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC,
> + VM_READ | VM_EXEC |
> + VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC |
> + VM_SEALED_SYSMAP,
> &info->code_mapping);
> if (IS_ERR(vma)) {
> ret = PTR_ERR(vma);
> --
> 2.49.0
>
Hi Lorenzo Stoakes, On 2025/4/15 21:58, Lorenzo Stoakes wrote: > I'm sure it's fine, but I am yet to encounter somebody enabling this for an > arch and saying 'I have checked to ensure we in no way rely on remapping > the VDSO, VVAR or any other special mapping'. > > Because if you haven't, doing this breaks your arch. > > I hate to sound like a grumpy maintainer, but could I just ask to check > whether you have, indeed, confirmed this? :) I've done some real-world testing before submitting. Before enabling MSEAL_SYSTEM_MAPPINGS, vdso/vvar is not sealed; after enabling MSEAL_SYSTEM_MAPPINGS, vdso/vvar is sealed. I tested the boot and shutdown of the Deepin 23 distribution, web Browse with Firefox, and document editing with LibreOffice both before and after enabling it, and I didn't encounter any issues (MSEAL_SYSTEM_MAPPINGS does cause a noticeable performance drop when outputting images via simple_drm, but I think this is expected). Of course, I also ran the self-tests provided by tools/testing/selftests/mseal_system_mappings, and all tests passed. I wanted to confirm if "breaks your arch" refers to the above? Do I need to perform any other kinds of tests to ensure the validity of this submission? > If so then all good. > > I also think we have a table somewhere in a doc that needs updating then? > Jeff, can you confirm? > > Thanks! > Thanks! -- WangYuli
On Tue, Apr 15, 2025 at 11:09:37PM +0800, WangYuli wrote: > Hi Lorenzo Stoakes, > > On 2025/4/15 21:58, Lorenzo Stoakes wrote: > > I'm sure it's fine, but I am yet to encounter somebody enabling this for an > > arch and saying 'I have checked to ensure we in no way rely on remapping > > the VDSO, VVAR or any other special mapping'. > > > > Because if you haven't, doing this breaks your arch. > > > > I hate to sound like a grumpy maintainer, but could I just ask to check > > whether you have, indeed, confirmed this? :) > > I've done some real-world testing before submitting. > > Before enabling MSEAL_SYSTEM_MAPPINGS, vdso/vvar is not sealed; after > enabling MSEAL_SYSTEM_MAPPINGS, vdso/vvar is sealed. > > I tested the boot and shutdown of the Deepin 23 distribution, web Browse > with Firefox, and document editing with LibreOffice both before and after > enabling it, and I didn't encounter any issues (MSEAL_SYSTEM_MAPPINGS does > cause a noticeable performance drop when outputting images via simple_drm, > but I think this is expected). I don't know why there would be any performance impact?... there shouldn't be. No this doesn't suffice, though thanks for doing this and confirming! You need to examine the arch specific code to ensure there is no code that remaps any of these system mappings. I went and checked <grumpy maintainer>(100% of arches submitted now it's been me who's checked so far :)</grumpy maintainer> and it appears that there is no such issue. So we seem to be good. > > Of course, I also ran the self-tests provided by > tools/testing/selftests/mseal_system_mappings, and all tests passed. > > I wanted to confirm if "breaks your arch" refers to the above? > > Do I need to perform any other kinds of tests to ensure the validity of this > submission? > > > If so then all good. > > > > I also think we have a table somewhere in a doc that needs updating then? > > Jeff, can you confirm? This is Documentation/features/core/mseal_sys_mappings/arch-support.txt I believe btw. > > > > Thanks! > > > Thanks! > > -- > WangYuli Overall if you send a v2 with doc changes I can ack maybe, but necessary to get a R-b from arch maintainers and I'd suggest it going through the arch tree.
© 2016 - 2025 Red Hat, Inc.