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: <5222dd9170d60b2ae93e24ce5d103c44cc1e36ea.camel@web.de>
Date: Wed, 09 Jul 2025 18:40:15 +0200
From: Bert Karwatzki <spasswolf@....de>
To: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
Cc: linux-kernel@...r.kernel.org, linux-next@...r.kernel.org, Thomas
 Gleixner	 <tglx@...utronix.de>, spasswolf@....de
Subject: Re: CONFIG_DEVMEM=y breaks gettimeofday in next-20250708

Am Mittwoch, dem 09.07.2025 um 15:17 +0200 schrieb Thomas Weißschuh:
> 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.

Yes, this fixes the issue for me.

> 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?

I use a MSI Alpha 15 B5EEK/MS-158L amd64 laptop (AMD Ryzen 7 5800H) running debian sid. When booting 
without "tsc=unstable" I get this message in dmesg (this is from next-20250708 with CONFIG_DEVMEM=y):

[    C7] clocksource: timekeeping watchdog on CPU7: Marking clocksource 'tsc' as unstable because the skew is too large:
[    C7] clocksource:                       'hpet' wd_nsec: 495997815 wd_now: 36f24f3 wd_last: 302c799 mask: ffffffff
[    C7] clocksource:                       'tsc' cs_nsec: 497721239 cs_now: 1ea2752100 cs_last: 1e43b3e700 mask: ffffffffffffffff
[    C7] clocksource:                       Clocksource 'tsc' skewed 1723424 ns (1 ms) over watchdog 'hpet' interval of 495997815 ns (495 ms)
[    C7] clocksource:                       'hpet' (not 'tsc') is current clocksource.
[    C7] tsc: Marking TSC unstable due to clocksource watchdog
[  T233] TSC found unstable after boot, most likely due to broken BIOS. Use 'tsc=unstable'.
[  T233] sched_clock: Marking unstable (4040049255, 1223348)<-(4058551237, -15591933)

I usually boot with "tsc=unstable" but the issue occurs there, too. I can't say yet why
this only occurs with CONFIG_DEVMEM=y.

Bert Karwatzki