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

Message-ID: <20251114093245-04b5eb56-d3ed-486b-90ff-7c7ad5cfc7e7@linutronix.de>
Date: Fri, 14 Nov 2025 09:48:41 +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 Fri, Nov 14, 2025 at 09:13:02AM +0100, Arnd Bergmann wrote:
> On Thu, Nov 13, 2025, at 16:30, Thomas Weißschuh wrote:
> > The vDSO selftests use raw system call wrapper to validate the
> > correctness of the vDSO implementation. The exactly available system
> > calls differ between architectures and kernel configurations.
> > Raw system calls should not use libc types as these are not necessarily
> > compatible.
> >
> > Introduce a helper header which uses the correct types and fallbacks.
> 
> After I looked at how these are used in patch 8, I think it's
> much easier to just always use the same types as the kernel interfaces
> here and skip the type mangling entirely:

Please see below.

> > +static inline
> > +int sys_clock_getres(__kernel_clockid_t clock, struct 
> > __kernel_timespec *ts)
> > +{
> > +#ifdef __NR_clock_getres_time64
> > +	return syscall(__NR_clock_getres_time64, clock, ts);
> > +#else
> > +	ASSERT_TIMESPEC_COMPATIBLE(typeof(*ts), struct __kernel_old_timespec);
> > +	return syscall(__NR_clock_getres, clock, ts);
> > +#endif
> > +}
> 
> __NR_clock_getres and vdso_clock_getres() both always return a
> __kernel_old_timespec, so I now think it's best to return that from
> sys_clock_getres() without the __NR_clock_getres_time64 alternative
> here and not worry about whether that is a 32-bit or 64-bit type,
>
> I should have thought this through better in my comments to the
> previous version.
> 
> In kernels without CONFIG_COMPAT_32BIT_TIME, we currently leave
> out the clock_getres/clock_gettime/gettimeofday/time syscalls,
> but still provide the vdso interfaces. For consistency we should
> probably leave out both syscall and vdso in that configuration,
> and then we also don't need to compare the vdso_getres result
> against sys_getres_time64.

That sounds good. But today no vDSO provides clock_getres_time64,
so removing clock_getres from the vDSO will affect users.
So we will end up with some sort of inconsistency in any case.
While I agree that it would be nice if the type mangling was unnecessary,
I prefer to correctly test what we have today. If we decide to simplify
the vDSO itself then we have working tests.

sys_clock_gettime() should probably be called sys_clock_gettime64(),
as that is what it actually is.

FYI: gettimeoday() seems to be available even in kernels without
CONFIG_COMPAT_32BIT_TIME.

Thomas