linux-kernel - Re: [PATCH] mseal sysmap: enable mips with LOONGSON64

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <ac2638ea-d44c-4b3d-b7a4-12862c7d58e9@lucifer.local>
Date: Thu, 17 Apr 2025 15:50:15 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Pedro Falcato <pfalcato@...e.de>
Cc: WangYuli <wangyuli@...ontech.com>, corbet@....net,
        tsbogend@...ha.franken.de, akpm@...ux-foundation.org,
        jeffxu@...omium.org, kees@...nel.org, Liam.Howlett@...cle.com,
        hca@...ux.ibm.com, takumaw1990@...il.com, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-mips@...r.kernel.org,
        thomas.weissschuh@...utronix.de, tglx@...utronix.de,
        namcao@...utronix.de, zhanjun@...ontech.com, niecheng1@...ontech.com,
        guanwentao@...ontech.com, Erpeng Xu <xuerpeng@...ontech.com>
Subject: Re: [PATCH] mseal sysmap: enable mips with LOONGSON64

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