linux-kernel - Re: [PATCH 1/2] rtc: m48t59: Accommodate chips that lack a century bit

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: <202410202018247178e729@mail.local>
Date: Sun, 20 Oct 2024 22:18:24 +0200
From: Alexandre Belloni <alexandre.belloni@...tlin.com>
To: Finn Thain <fthain@...ux-m68k.org>
Cc: Geert Uytterhoeven <geert@...ux-m68k.org>,
	Daniel Palmer <daniel@...f.com>,
	Michael Pavone <pavone@...rodev.com>,
	linux-m68k@...ts.linux-m68k.org, linux-rtc@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] rtc: m48t59: Accommodate chips that lack a century
 bit

On 05/10/2024 14:23:28+1000, Finn Thain wrote:
> 
> On Thu, 3 Oct 2024, Alexandre Belloni wrote:
> 
> > 
> > ... while you are it, can you use m48t59->rtc->start_secs and 
> > m48t59->rtc->set_start_time in probe instead of offsetting tm_year in 
> > read_time/set_time so we can later use device tree or any other 
> > mechanism to extend the range?
> > 
> 
> That didn't work out as I'd hoped. I booted a patched kernel (diff below) 
> under qemu-system-sparc64:
> 
> ~ # for yyyy in 1970 1971 1999 2000 2024 2025 2068 2069 ; do 
> date 01010101$yyyy ; hwclock --systohc --utc && hwclock --utc ; echo ; done
> Thu Jan  1 01:01:00 UTC 1970
> Thu Jan  1 01:01:00 1970  0.000000 seconds
> 
> Fri Jan  1 01:01:00 UTC 1971
> Tue Nov 24 18:32:44 1998  0.000000 seconds
> 
> Fri Jan  1 01:01:00 UTC 1999
> Tue Nov 24 18:32:44 2026  0.000000 seconds
> 
> Sat Jan  1 01:01:00 UTC 2000
> Sun Jan  2 23:29:16 2000  0.000000 seconds
> 
> Mon Jan  1 01:01:00 UTC 2024
> Tue Jan  2 23:29:16 2024  0.000000 seconds
> 
> Wed Jan  1 01:01:00 UTC 2025
> Thu Jan  2 23:29:16 2025  0.000000 seconds
> 
> Sun Jan  1 01:01:00 UTC 2068
> hwclock: RTC_SET_TIME: Numerical result out of range
> 
> Tue Jan  1 01:01:00 UTC 2069
> hwclock: RTC_SET_TIME: Numerical result out of range
> 
> ~ # 
> 
> Here's the result from an unpatched kernel (v6.11):
> 
> ~ # for yyyy in 1970 1971 1999 2000 2024 2025 2068 2069 ; do 
> date 01010101$yyyy ; hwclock --systohc --utc && hwclock --utc ; echo ; done
> Thu Jan  1 01:01:00 UTC 1970
> Thu Jan  1 01:01:00 1970  0.000000 seconds
> 
> Fri Jan  1 01:01:00 UTC 1971
> Fri Jan  1 01:01:00 1971  0.000000 seconds
> 
> Fri Jan  1 01:01:00 UTC 1999
> Fri Jan  1 01:01:01 1999  0.000000 seconds
> 
> Sat Jan  1 01:01:00 UTC 2000
> Sat Jan  1 01:01:00 2000  0.000000 seconds
> 
> Mon Jan  1 01:01:00 UTC 2024
> Mon Jan  1 01:01:00 2024  0.000000 seconds
> 
> Wed Jan  1 01:01:00 UTC 2025
> Wed Jan  1 01:01:00 2025  0.000000 seconds
> 
> Sun Jan  1 01:01:00 UTC 2068
> hwclock: RTC_RD_TIME: Invalid argument
> 
> Tue Jan  1 01:01:00 UTC 2069
> hwclock: RTC_RD_TIME: Invalid argument
> 
> ~ # 
> 
> 
> I'm afraid I don't see how we might avoid adding/subtracting in 
> read_time/set_time given that we must avoid messing up the present date 
> when users boot into an upgraded kernel.

I'm pretty sure this is avoidable as this is exactly what the offset
mechanism is trying to achieve. I guess the issue is in the RTC core
because both range_min and start_secs are negative which has never been
tested. My plan was to have unit tests for this but this never
happened...


-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com