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: <568AA1C2.2070407@android.com>
Date:	Mon, 4 Jan 2016 08:45:54 -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 08:18 AM, Alexandre Belloni wrote:
> Hi,
>
> On 30/12/2015 at 12:51:45 -0800, Mark Salyzyn wrote :
>> Replace bcd2bin and bin2bcd with one that maps years 1970 to 2129
>> in a pattern that works with the underlying hardware.
>>
>> The only transition that does not work correctly for this rtc clock
>> is the transition from 2099 to 2100, it proceeds to 2000. The rtc
>> clock retains and transitions the year correctly in all other
>> circumstances.
>>
> If that transition doesn't work, it is not useful to try to support
> dates after 2099. Also, I'm concerned about the leap year handling in
> the other case. What is done right now is probably the best however, I
> couldn't find the datasheet to confirm.
>

As it stands today, if I set the date to 1970, it returns 2066, so this 
is a leap(sic) forward for this one rtc clock.

The advantages of supporting 2099+ for being able to set those years and 
not return garbage like in the 1970 case. The failure to roll over from 
2099-2100 is but a millisecond of failure for an additional 1/3 of 
century of well being, and support code is minor, albeit flawed. Without 
these additional four lines, if something sets the year to 2100, they 
will get a garbage back in return, a small price to pay IMHO.

There are dozens and dozens of other bcd-based rtc clocks that could 
gain from this example (and may not have this issue with 2099 rollover), 
so maybe this year code should be in the library?

I will remove 2099+ support if you continue to consider this rollover 
issue egregious given my rationalization.

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/