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: <5826549e-88a8-429c-ad42-46aeada9d21b@app.fastmail.com>
Date: Fri, 14 Nov 2025 09:13:02 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: Thomas Weißschuh <thomas.weissschuh@...utronix.de>,
 "Andy Lutomirski" <luto@...nel.org>, "Thomas Gleixner" <tglx@...utronix.de>,
 "Vincenzo Frascino" <vincenzo.frascino@....com>, shuah <shuah@...nel.org>
Cc: linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH v2 03/14] selftests: vDSO: Introduce vdso_syscalls.h

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:

> +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.

> +static inline
> +int sys_clock_gettime(__kernel_clockid_t clock, struct 
> __kernel_timespec *ts)
> +{
> +#ifdef __NR_clock_gettime64
> +	return syscall(__NR_clock_gettime64, clock, ts);
> +#else
> +	ASSERT_TIMESPEC_COMPATIBLE(typeof(*ts), struct __kernel_old_timespec);
> +	return syscall(__NR_clock_gettime, clock, ts);
> +#endif
> +}

Same here.

> +static inline
> +int sys_gettimeofday(struct __kernel_old_timeval *tv, struct 
> kernel_timezone *tz)
> +{
> +#ifdef __NR_gettimeofday
> +	return syscall(__NR_gettimeofday, tv, tz);
> +#else
> +	/* Architectures with vdso_gettimeofday() also have __NR_gettimeofday 
> */
> +	errno = ENOSYS;
> +	return -1;
> +#endif
> +}
> +
> +static inline
> +__kernel_old_time_t sys_time(__kernel_old_time_t *tloc)
> +{
> +#ifdef __NR_time
> +	return syscall(__NR_time, tloc);
> +#else
> +	/* Architectures with vdso_time() also have __NR_time */
> +	errno = ENOSYS;
> +	return -1;
> +#endif
> +}

These both look good to me.

     Arnd