linux-kernel - Re: [PATCH v2 03/14] selftests: vDSO: Introduce vdso

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: <20251120142528-86237d98-17b3-480a-a2f4-3d88e5969e9e@linutronix.de>
Date: Thu, 20 Nov 2025 14:27:54 +0100
From: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
To: Arnd Bergmann <arnd@...db.de>
Cc: Andy Lutomirski <luto@...nel.org>, 
	Thomas Gleixner <tglx@...utronix.de>, Vincenzo Frascino <vincenzo.frascino@....com>, 
	shuah <shuah@...nel.org>, linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH v2 03/14] selftests: vDSO: Introduce vdso_syscalls.h

On Tue, Nov 18, 2025 at 10:40:03PM +0100, Arnd Bergmann wrote:
> On Tue, Nov 18, 2025, at 15:22, Thomas Weißschuh wrote:
> > On Fri, Nov 14, 2025 at 11:40:31AM +0100, Arnd Bergmann wrote:
> >> On Fri, Nov 14, 2025, at 11:02, Thomas Weißschuh wrote:
> >> > On Fri, Nov 14, 2025 at 10:16:01AM +0100, Arnd Bergmann wrote:
> >> >
> >> > I don't think it is important. For my SPARC vDSO series I even
> >> > dropped the regular clock_getres() after your request. But because it
> >> > doesn't exist we need to handle the presence of vdso_clock_getres() and
> >> > the simultaneous absence of sys_clock_getres() in the test.
> >> 
> >> But that is the other way round, right? On sparc32 we have
> >> (optionally) sys_clock_getres() but never vdso_clock_getres().
> >
> > Here SPARC was just an example to show that I don't really care about
> > clock_getres() in the vDSO in general.
> > But if it was present before for an architecture and we now drop it without a
> > replacement, userspace developers might complain. Manually caching the value
> > in userspace sounds ugly and brittle, as it could even change at some point.
> > Introducing a time64 replacement on the other hand wouldn't make much
> > difference as the values never would exceed the 32-bit range anyways.
> >
> > So I would keep vdso_clock_getres() where it exists today even with
> > CONFIG_COMPAT_32BIT_TIME=n.
> 
> It is rather inconsistent with all the other interfaces though:
> when we originally did the time64 conversion, there were a number
> of interfaces that didn't really need a replacement, but we
> deliberately made new interfaces wherever possible. For architectures
> without time32 support, and for validating the time64 support,
> it should be possible to build both kernel and userspace without
> even defining the __kernel_old_time{_t,spec,val} types.

Fair enough. I'll add this to my TODO list.

> >> Right, but then I would make it return 'struct timespec', not
> >> 'struct __kernel_timespec', because it's no longer the kernel
> >> interface.

(...)


Thomas