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] [thread-next>] [day] [month] [year] [list]

Message-ID: <568BEA92.2090701@android.com>
Date:	Tue, 5 Jan 2016 08:08:50 -0800
From:	Mark Salyzyn <salyzyn@...roid.com>
To:	Alexandre Belloni <alexandre.belloni@...e-electrons.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 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)

Sincerely -- Mark Salyzyn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/