Provide support for CONFIG_MSEAL_SYSTEM_MAPPINGS on mips with
CPU_LOONGSON64, covering the vdso.

NOTE:
  There is significant diversity among devices within the MIPS
architecture, which extends to their kernel code implementations.
  My testing capabilities are limited to Loongson 3A4000/3B4000
CPUs.
  Consequently, I have not enabled mseal sysmap support for the
entirety of mips64, as I lack the necessary devices for testing.

Tested-by: Erpeng Xu <xuerpeng@uniontech.com>
Tested-by: WangYuli <wangyuli@uniontech.com>
Signed-off-by: WangYuli <wangyuli@uniontech.com>
---
NOTE:
  1. As I am unaware whether other 64-bit MIPS devices function
properly, I have not yet modified the MIPS status in
mseal_sys_mappings/arch-support.txt.
  2. From my perspective, it appears that this architecture also
does not rely on remapping the VDSO, VVAR, or any other special
mapping. Nevertheless, I believe it would be best to get further
confirmation from more expert individuals such as Lorenzo Stoakes
and Thomas Bogendoerfer.
---
 Documentation/userspace-api/mseal.rst | 2 +-
 arch/mips/Kconfig                     | 1 +
 arch/mips/kernel/vdso.c               | 3 ++-
 3 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/Documentation/userspace-api/mseal.rst b/Documentation/userspace-api/mseal.rst
index ea9b11a0bd89..968a6db8afb7 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,
-  loongarch and s390.
+  loongarch, mips64el (loongson3) 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/mips/Kconfig b/arch/mips/Kconfig
index fc0772c1bad4..055a185deb07 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -25,6 +25,7 @@ config MIPS
 	select ARCH_USE_QUEUED_RWLOCKS
 	select ARCH_USE_QUEUED_SPINLOCKS
 	select ARCH_SUPPORTS_HUGETLBFS if CPU_SUPPORTS_HUGEPAGES
+	select ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS if CPU_LOONGSON64
 	select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU
 	select ARCH_WANT_IPC_PARSE_VERSION
 	select ARCH_WANT_LD_ORPHAN_WARN
diff --git a/arch/mips/kernel/vdso.c b/arch/mips/kernel/vdso.c
index de096777172f..6221f2dcedb1 100644
--- a/arch/mips/kernel/vdso.c
+++ b/arch/mips/kernel/vdso.c
@@ -167,7 +167,8 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 	/* Map VDSO image. */
 	vma = _install_special_mapping(mm, vdso_addr, image->size,
 				       VM_READ | VM_EXEC |
-				       VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC,
+				       VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC |
+				       VM_SEALED_SYSMAP,
 				       &image->mapping);
 	if (IS_ERR(vma)) {
 		ret = PTR_ERR(vma);
-- 
2.49.0

On Thu, Apr 17, 2025 at 09:24:10PM +0800, WangYuli wrote:
> Provide support for CONFIG_MSEAL_SYSTEM_MAPPINGS on mips with
> CPU_LOONGSON64, covering the vdso.
> 
> NOTE:
>   There is significant diversity among devices within the MIPS
> architecture, which extends to their kernel code implementations.
>   My testing capabilities are limited to Loongson 3A4000/3B4000
> CPUs.
>   Consequently, I have not enabled mseal sysmap support for the
> entirety of mips64, as I lack the necessary devices for testing.
>

I strongly suggest we don't do this kind of stuff. Lets keep things simple and either:

1) Check that there's no problem for _all_ variations of the arch. Then enable
   ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS.
2) If not checking everything, then don't do any sort of enabling.

It should help reduce confusion.

And, to be clear for folks not following mseal, this feature is rather small and not a
priority in any way (and will not be enabled in linux distros for a whole bunch of years,
due to the current situation being unworkable for !chromeOS). There's really no rush
in having this enabled for all architectures.

-- 
Pedro

On Thu, Apr 17, 2025 at 03:27:16PM +0100, Pedro Falcato wrote:
> On Thu, Apr 17, 2025 at 09:24:10PM +0800, WangYuli wrote:
> > Provide support for CONFIG_MSEAL_SYSTEM_MAPPINGS on mips with
> > CPU_LOONGSON64, covering the vdso.
> >
> > NOTE:
> >   There is significant diversity among devices within the MIPS
> > architecture, which extends to their kernel code implementations.
> >   My testing capabilities are limited to Loongson 3A4000/3B4000
> > CPUs.
> >   Consequently, I have not enabled mseal sysmap support for the
> > entirety of mips64, as I lack the necessary devices for testing.
> >
>
> I strongly suggest we don't do this kind of stuff. Lets keep things simple and either:
>
> 1) Check that there's no problem for _all_ variations of the arch. Then enable
>    ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS.
> 2) If not checking everything, then don't do any sort of enabling.
>
> It should help reduce confusion.

I agree, I think this would work better in one go for each
architecture. There really is no rush as Pedro says :)

>
> And, to be clear for folks not following mseal, this feature is rather small and not a
> priority in any way (and will not be enabled in linux distros for a whole bunch of years,
> due to the current situation being unworkable for !chromeOS). There's really no rush
> in having this enabled for all architectures.

Given that a bunch of userland is broken by this, it's unlikely to be
enabled by default in any distro any time soon (at least sensibly).

So this underlines the fact that there is not a huge amount of urgency
here.

>
> --
> Pedro

As for the kind of checks you need to do to ensure there is no remapping of
system mappings - generally tracing through how VDSO and VVAR is used
within the architecture code suffices.

An idealised form of this would be somebody stating something like:

	I see the vdso is allocated and mapped in init_vdso_blah(), and
	from then on in the address of the VDSO is referenced in a
	read-only fashion in internal metadata field XYZ, equally so VVAR
	[similar argument]...

Something like this would suffice, where you have traced through usage
patterns.

It might sound like an ominous or difficult task, but generally when I've
done it it's taken me 10 - 15 minutes. If you want to be thorough you might
want to spend a little longer, however.

I also would strongly suggest providing a motivation for the change, as you
would expect with any series - right now it is essentially 'just enable X
for Y' - ok, but why? What for? etc.

It's really vital to ensure you truly understand the feature you are
enabling, the limitations, drawbacks as well as the benefits, and to ensure
you understand what might break.

If I were to bet on it, I'd suggest probably only one or two arches
actually would experience _any_ problem with system mapping sealing in
_kernel_ code.

Userland is curently broken for a number of applications (only the ones we
know about, who knows what others are broken), but this is known,
documented, and anybody who enables the config option is essentially saying
'I don't mind breaking certain userspace'.

I feel like I might need to repeat this explanation a few times again :) so
I may bookmark this reply and refer to it for others enabling this
elsewhere.

Thanks, Lorenzo