linux-kernel - Re: CONFIG_DEVMEM=y breaks gettimeofday in next-20250708

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: <20250709150929-7198f921-5b85-461a-acc1-ccc04e9adbab@linutronix.de>
Date: Wed, 9 Jul 2025 15:17:03 +0200
From: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
To: Bert Karwatzki <spasswolf@....de>
Cc: linux-kernel@...r.kernel.org, linux-next@...r.kernel.org, 
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: CONFIG_DEVMEM=y breaks gettimeofday in next-20250708

Hi Bert,

On Wed, Jul 09, 2025 at 02:42:15PM +0200, Bert Karwatzki wrote:
> Recently I found that my RAM has an error (memtest86+ reproducibly reports
> a failing address) (this error may lead to random crashes every few days). 
> To further investigate the issue I tried using memtester which needs access 
> to /dev/mem and so I recompiled linux next-20250708 with CONFIG_DEMEM=y 
> and found a strange and unusual side effect:
> 
> a) the time displayed by xfce is stuck at 1.1.1970 01:00 (UTC + 1)
> b) most certificates in firefox-esr fail to work due to the date being 1.1.1970 
> (this includes www.google.de, www.duckduckgo.com, wikipedia and youtube and many more)
> c) some certificates in firefox-esr still work (kernel.org, xkcd.com, www.spiegel.de)
> d) the shell built-in time (and also /usr/bin/time) fail to work, e.g.
> $ time sleep 5
> real	0m0,000s
> user	0m0,000s
> sys	0m0,002s
> (even though it actually take 5 seconds for this)
> e) date still works correctly, e.g.
> $ date
> Mi 9. Jul 11:51:20 CEST 2025
> f) This example program 
> 
> #include <stdlib.h>
> #include <stdio.h>
> #include <sys/time.h>
> 
> int main()
> {
> 	int ret;
> 	struct timeval tv;
> 	struct timezone tz;
> 
> 	ret = gettimeofday(&tv, &tz);
> 	printf("gettimeofday returns ret = %d, tv.tv_sec = %lu tv.tv_usec = %lu\n", ret, tv.tv_sec, tv.tv_usec);
> 
> 	return 0;
> }
> 
> gives the following output on affected versions:
> 
> $
> gettimeofday returns ret = 0, tv.tv_sec = 0 tv.tv_usec = 0

Thanks for the report. Can you try the fix posted by Marek [0]?
It looks like the same issue where the vDSO fastpath is unavailable on your
hardware but I broke the check for it.
If it is the same issue it still leaves the question why the fastpath is
broken by CONFIG_DEVMEM. Can you describe your setup a bit?
Are there any entries in dmesg about the tsc or the clocksource subsystem?

> These errors do not occur when using v6.16-rc5 with CONFIG_DEVMEM=y, and are 100%
> reproducible so are not related to the RAM error. 
> 
> I bisected the issue in between
> v6.16-rc5 and next-20250708 and found commit fcc8e46f768f ("vdso/gettimeofday:
> Return bool from clock_gettime() helpers") as the first bad commit.

[0] https://lore.kernel.org/lkml/e8c6b9a7-eaa6-4947-98e1-9d6fecc958d4@samsung.com/