linux-kernel - Re: rtc-palmas: correct for bcd year

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: <20160708141023.GH22202@piout.net>
Date:	Fri, 8 Jul 2016 16:10:23 +0200
From:	Alexandre Belloni <alexandre.belloni@...e-electrons.com>
To:	Mark Salyzyn <salyzyn@...roid.com>
Cc:	linux-kernel@...r.kernel.org,
	Alessandro Zummo <a.zummo@...ertech.it>,
	rtc-linux@...glegroups.com
Subject: Re: rtc-palmas: correct for bcd year

On 05/01/2016 at 08:08:50 -0800, Mark Salyzyn wrote :
> On 01/04/2016 04:00 PM, Alexandre Belloni wrote:
> > I'd say that the proper course of action is to refuse to set dates
> > before 2000 and after 2100. See
> > http://patchwork.ozlabs.org/patch/541037/
> Got it.
> 
> We have an issue though, Android (or rather any embedded) devices must
> continue to function when date is manually set to any value between 1970 and
> 2037. The issue here is a fresh device with a recently charged battery will
> _start_ at 1970 until ntp or cell time/date/locale is set and the device
> must continue to function in this vacuum. A device reboot should not result
> in the other calendar values being reset, should the year be wrong, as this
> will result in a bad user experience.
> 
> We will have to use a different patch on Android than upstream if dates
> before 2000 are deprecated.
> 
> All other factors (rollover, leap) can be corrected by frameworks and
> runtime since the rtc is generally secondary (ie: first rtc driver was in
> 1979, created a daemon to correct the flaws in the hardware clock using a
> cron job)
> 

Well, I was still thinking about that issue but while handling properly
a gap in the RTC continuity is impossible, it is actually easy to handle
an offset in the RTC by using mktime and then offseting the resulting
time_t. Of course you'll then need to handle leap years and the likes
but you said that was not an issue for you.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com