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