linux-kernel - Re: [PATCH v5 00/34] sparc64: vdso: Switch to the generic vDSO library

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: <6452c785-872a-4fe7-90e1-8138d73c6218@app.fastmail.com>
Date: Sat, 08 Nov 2025 11:17:46 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Andy Lutomirski" <luto@...nel.org>,
 Thomas Weißschuh <thomas.weissschuh@...utronix.de>,
 "Thomas Gleixner" <tglx@...utronix.de>,
 "Vincenzo Frascino" <vincenzo.frascino@....com>,
 "David S . Miller" <davem@...emloft.net>,
 "Andreas Larsson" <andreas@...sler.com>,
 "Nick Alcock" <nick.alcock@...cle.com>,
 "John Stultz" <jstultz@...gle.com>, "Stephen Boyd" <sboyd@...nel.org>,
 "John Paul Adrian Glaubitz" <glaubitz@...sik.fu-berlin.de>,
 shuah <shuah@...nel.org>, "Catalin Marinas" <catalin.marinas@....com>,
 "Will Deacon" <will@...nel.org>, "Theodore Ts'o" <tytso@....edu>,
 "Jason A . Donenfeld" <Jason@...c4.com>,
 "Russell King" <linux@...linux.org.uk>,
 "Madhavan Srinivasan" <maddy@...ux.ibm.com>,
 "Michael Ellerman" <mpe@...erman.id.au>,
 "Nicholas Piggin" <npiggin@...il.com>,
 "Christophe Leroy" <christophe.leroy@...roup.eu>,
 "Huacai Chen" <chenhuacai@...nel.org>, "WANG Xuerui" <kernel@...0n.name>,
 "Thomas Bogendoerfer" <tsbogend@...ha.franken.de>,
 "Heiko Carstens" <hca@...ux.ibm.com>,
 "Vasily Gorbik" <gor@...ux.ibm.com>,
 "Alexander Gordeev" <agordeev@...ux.ibm.com>,
 "Christian Borntraeger" <borntraeger@...ux.ibm.com>,
 "Sven Schnelle" <svens@...ux.ibm.com>,
 "Shannon Nelson" <sln@...main.com>
Cc: "Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
 sparclinux@...r.kernel.org, linux-kselftest@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linuxppc-dev@...ts.ozlabs.org,
 loongarch@...ts.linux.dev, linux-mips@...r.kernel.org,
 linux-s390@...r.kernel.org, "Arnd Bergmann" <arnd@...nel.org>
Subject: Re: [PATCH v5 00/34] sparc64: vdso: Switch to the generic vDSO library

On Sat, Nov 8, 2025, at 01:17, Andy Lutomirski wrote:
> On Thu, Nov 6, 2025, at 2:01 AM, Thomas Weißschuh wrote:
>
> Now I'm not an expert on any architecture that has these aliasing 
> (coloring?) issues, but from my limited understanding, it ought to be 
> possible to choose a correctly colored address to map the vdso data 
> given where it's being mapped from.  If there's an issue with gathering 
> a bunch of basically arbitrarily relatively positioned physical pages 
> into their necessary arrangement in usermode, you could presumably fix 
> it either with some linker script magic or by rearranging the C code to 
> stick everything into a multipage structure.

On 32-bit Arm, we only allow VDSO on CPUs that have nonaliasing caches
but not on the rare ARMv4/v5 CPUs. From the public information I could
find, it appears that similarly all SPARC CPUs from the past 20 years
(Leon 3/4/5, SPARC64, Niagara, M5/M6/M7/M8, ...) are also nonaliasing,
though at least UltraSPARC IV (released 2004) and earlier models still
had an aliasing VIPT dcache.

Someone more familiar with SPARC should double-check that, but I would
expect that we can gate the VDSO on the actual cache topology.

On other architectures, I see that parisc (always aliasing) has stubbed
out the vdso functions, while mips/loongson has limited the page size
selection to never alias. A few other mips platforms can theoretically
enable both small pages and vdso, but my guess is that in practice
they don't use the vdso (mips32/ath79) or they use 16KB pages
(rm, dec, ip22) based on the defconfig settings.

      Arnd