linux-kernel - Re: [PATCH 1/2] vdso: sparc: stub out custom vdso implementation

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250708085740-dc559080-2551-427c-9134-41fa7f9898d1@linutronix.de>
Date: Tue, 8 Jul 2025 09:13:25 +0200
From: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
To: Arnd Bergmann <arnd@...db.de>
Cc: Arnd Bergmann <arnd@...nel.org>, Thomas Gleixner <tglx@...utronix.de>, 
	"David S . Miller" <davem@...emloft.net>, Andreas Larsson <andreas@...sler.com>, 
	Andy Lutomirski <luto@...nel.org>, Vincenzo Frascino <vincenzo.frascino@....com>, 
	shuah <shuah@...nel.org>, Anna-Maria Gleixner <anna-maria@...utronix.de>, 
	Frederic Weisbecker <frederic@...nel.org>, John Stultz <jstultz@...gle.com>, 
	Stephen Boyd <sboyd@...nel.org>, Catalin Marinas <catalin.marinas@....com>, 
	Will Deacon <will@...nel.org>, Eric Biggers <ebiggers@...gle.com>, sparclinux@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Helge Deller <deller@....de>
Subject: Re: [PATCH 1/2] vdso: sparc: stub out custom vdso implementation

On Tue, Jul 08, 2025 at 08:40:27AM +0200, Arnd Bergmann wrote:
> On Tue, Jul 8, 2025, at 07:39, Thomas Weißschuh wrote:

(...)

> > But why do we even need the stubs? Removing the time functions from the
> > vDSO completely should also work, no?
> > For parisc there was no reasoning why stubs were used. On uml the stubs are
> > necessary to prevent the libc from calling into the host vsyscall [0], but
> > that looks irrelevant for SPARC.
> >
> > [0] f1c2bb8b9964 ("um: implement a x86_64 vDSO")
> 
> I was wondering about this myself, I thought this might have been
> for runtime environments that just assume the vDSO is there, possibly
> some non-C libraries, or future glibc versions that may error
> out when the vdso is absent instead of falling back to the syscall.

libc erroring out if the vdso is missing sounds unlikely to me.

(...)

> The arch/x86/um/vdso/um_vdso.c version for 32-bit seems to still
> be missing the clock_gettime64() entry, any idea what the
> resulting behavior is for time64 userspace?

The vsyscall page is for 64-bit userspace only, and I think always ways.

In any case, modern distro kernels don't provide the vsyscall page at all or
emulate it through syscall stubs, which are affected by the uml host access issue.
Also glibc dropped vsyscall page support in 2020.


Thomas