linux-kernel - Re: [PATCH 12/14] vdso/gettimeofday: Add support for auxiliary clocks

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: <20250820113704-8b174953-f02a-4376-9359-e4007914ac2a@linutronix.de>
Date: Wed, 20 Aug 2025 12:15:05 +0200
From: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
To: John Stultz <jstultz@...gle.com>
Cc: Andy Lutomirski <luto@...nel.org>, 
	Thomas Gleixner <tglx@...utronix.de>, Vincenzo Frascino <vincenzo.frascino@....com>, 
	Shuah Khan <shuah@...nel.org>, Anna-Maria Behnsen <anna-maria@...utronix.de>, 
	Frederic Weisbecker <frederic@...nel.org>, Stephen Boyd <sboyd@...nel.org>, 
	Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>, Arnd Bergmann <arnd@...db.de>, 
	linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org, 
	linux-arm-kernel@...ts.infradead.org, linux-arch@...r.kernel.org, 
	Richard Cochran <richardcochran@...il.com>, Christopher Hall <christopher.s.hall@...el.com>, 
	Miroslav Lichvar <mlichvar@...hat.com>, Werner Abt <werner.abt@...nberg-usa.com>, 
	David Woodhouse <dwmw2@...radead.org>, Kurt Kanzenbach <kurt@...utronix.de>, 
	Nam Cao <namcao@...utronix.de>, Antoine Tenart <atenart@...nel.org>
Subject: Re: [PATCH 12/14] vdso/gettimeofday: Add support for auxiliary clocks

Hi John,

On Wed, Aug 20, 2025 at 01:03:56AM -0700, John Stultz wrote:
> On Tue, Jul 1, 2025 at 1:58 AM Thomas Weißschuh
> <thomas.weissschuh@...utronix.de> wrote:
> >
> > Expose the auxiliary clocks through the vDSO.
> >
> > Architectures not using the generic vDSO time framework,
> > namely SPARC64, are not supported.
> >
> > Signed-off-by: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
> 
> Just as a heads up, I've just been bisecting and this commit seems to
> be causing problems on arm64 devices, running 32bit versions of
> kselftest nanosleep or inconsistency-check tests. Running the 64bit
> versions of the tests are not showing issues.

Thanks for the report, I can reproduce the issue.

> From my initial digging, it looks like clockids that aren't vdso
> enabled (CLOCK_PROCESS_CPUTIME_ID, CLOCK_THREAD_CPUTIME_ID,
> CLOCK_REALTIME_ALARM, CLOCK_BOOTTIME_ALARM) are somehow getting caught
> in the vdso logic and are *not* falling back to the syscall (stracing
> the test I don't see syscalls happen before the failure), and the
> values returned don't look to be correct.

The generic vDSO code assumes that it can use the UAPI headers, also in the
compat vDSO. This is true for most architectures, as the UAPI headers work
correctly in 32-bit and 64-bit mode. On arm64 this is different, as the headers
from arm64/ are never used by regular 32-bit userpspace. So
arch/arm64/include/uapi/asm/bitsperlong.h defines __BITS_PER_LONG=64 even when
used by the 32-bit compat vDSO. The commit you identified uses __GENMASK()
which uses __BITS_PER_LONG. Due to the mismatch between __BITS_PER_LONG and the
real long datatype we run into an out-of-bounds shift and therefore undefined
behaviour. And of course -Wshift-count-overflow is explicitly disabled.

There are a few possible fixes, none of which is really great.
I'll send some patches.

> The inconsistency-check output looks like:

(...)

> Which hints we're returning nanosecond values in the tv_sec field somehow.

That seems to be an artifact of the UB from above, this happens even if
do_aux() just returns 'false'.


Thomas