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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20191003213452.GT4106@piout.net>
Date:   Thu, 3 Oct 2019 23:34:52 +0200
From:   Alexandre Belloni <alexandre.belloni@...tlin.com>
To:     Lukasz Majewski <lukma@...x.de>
Cc:     Alessandro Zummo <a.zummo@...ertech.it>, linux-rtc@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] rtc: Add support for century bits to m41t62 (rv4162) RTC
 devices

On 03/10/2019 16:49:06+0200, Lukasz Majewski wrote:
> Hi Alexandre,
> I'm rather thinking about following use cases:
> 
> I. Adjusting time:
> 
> 1. I start with time < 01.01.2099
> 
> 2. I issue ioctl to set the time to e.g. 2100
> 
> 	- When driver receives such request I setup century bits
> 
> 	- and also perform in kernel driver time correction (and store
> 	  corrected time in RTC)
> 
> 3. Subsequent reads from rtc use century bits to provide the time
> (after year 2100). Century bits are set, so the correction may be
> performed if needed.
> 
> 
> II. The system is started at year 2098 and is supposed to run for e.g. 3
> years:
> 
> 1. The time is read from the rtc - the "passing" of centuries need to
> be detected.
> 
> From the documentation [1] (point 4.5):
> 
> "The two century bits, CB1 and CB0, are bits 7 and 6, respectively, in
> the Month / Century register at address 06h. Together, they comprise a
> 2 - bit counter which increments at the turn of each century. CB1 is
> the most significant bit."
> 
> If those bits increment when we pass century boundaries, we can detect
> this fact and correct time when ioctl is issued.
> 

No, you can't because you simply don't know if you still need to
correct the time or if you already did it the last time the system was
started.

Example:

Date is set to 2100-02-28, some time pass, the rtc now thinks it is
2100-02-29. You correct it to 2100-03-01, fine.
Now, date is set to 2100-02-28, the system is shutdown, some time pass,
it starts on 2100-03-02, the rtc thinks 2100-03-01 you can't correct it
because you can't know whether a day has been missed.


> > The only useful range for an RTC is its fully contiguous range. 
> 
> Does the automatic increment of century bits count to "contiguous
> range" ?
> 

No, because of the leap day issue.


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ