linux-kernel - Re: [PATCH 00/25] Change time_t and clock

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

Message-ID: <537406FA.2040906@zytor.com>
Date:	Wed, 14 May 2014 17:14:50 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	John Stultz <john.stultz@...aro.org>, Arnd Bergmann <arnd@...db.de>
CC:	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Christoph Hellwig <hch@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ley Foon Tan <lftan@...era.com>,
	Linux-Arch <linux-arch@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	LeyFoon Tan <lftan.linux@...il.com>,
	Chung-Lin Tang <cltang@...esourcery.com>
Subject: Re: [PATCH 00/25] Change time_t and clock_t to 64 bit

On 05/14/2014 02:33 PM, John Stultz wrote:
> 
> We can do some tricks for internal optimizations here if these are
> critical.  I'd be more concerned about userland divisions where moving
> to a 64bit time_t would cause performance issues that we cannot help
> optimize.
> 

Honestly, the cost of not addressing the Y2038 problem in plenty of time
is going to be way, way, way, way more expensive than some additional
arithmetic.

As far as converting to calendar notation (e.g. the Gregorian calendar),
only the first division needs to be done with full time_t width.
Furthermore, since the divisor is known a priori, the compiler *should*
be able to do it as an inverse multiply.[1]

The remaining divisions are bounded, and a smart compiler should even
know that.

> I'm not sure I'm totally following this... Are you suggesting we keep
> 32bit time internally w/ some different offset but then pass to
> userland a 64bit time_t?  Or are you suggesting we change the abi to
> move the epoch?

I think this makes sense as a way of emergency rescue of legacy ABIs --
similar to the windowing solution used to Y2K-rescue legacy systems.
Nonlegacy ABIs should just be designed correctly from the start.

> I think I'm with hpa in his recent mail in that the internal
> representation is an optimization detail, and the bigger question is146
> do we use a  64bit time_t for future systems (possibly w/ a major ABI
> break - with compat interface for existing 32bit applications), or do
> we try to rev interfaces function by function to provide 2038 safe
> versions which applications will have to be modified to use?
> 
> Me, I'm a fan of moving time_t to 64bits, since it makes "porting"
> applications to a 2038 safe ABI easier.

I obviously couldn't agree more.

	-hpa

[1] Not entirely true: the highest possible divisor necessary when doing
Gregorian calendar calculations is 12_622_780_800 (0x2_f060_5980), the
number of seconds in each Gregorian 400-year cycle.  Similarly, dividing
with 86400 first to separate time and date requires the date part of the
result to remain 64 bits until the next division.  Thus, depending on
exactly how the calculations are partitioned it may be necessary to do
two 64-bit wide divisions; this can, however, be avoided with some care.

--
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/