linux-kernel - Re: [PATCH] timekeeping: handle epoch roll-over (2038) on 32-bit systems

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]

Date:	Mon, 03 Jun 2013 12:04:14 -0700
From:	John Stultz <john.stultz@...aro.org>
To:	Thomas Gleixner <tglx@...utronix.de>
CC:	Tobias Waldekranz <tobias@...dekranz.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH] timekeeping: handle epoch roll-over (2038) on 32-bit
 systems

On 06/03/2013 07:34 AM, Thomas Gleixner wrote:
> B1;2601;0cOn Mon, 3 Jun 2013, Tobias Waldekranz wrote:
>> In ktime_get_update_offsets, calculate the current time in the same
>> way as in ktime_get.
>>
>> On 32-bit systems, the current time is truncated via the call to
>> ktime_set, the following subtraction of offs_real will result in an
>> inaccurate time when the current number of seconds since epoch can no
>> longer fit in 31-bits (2038-01-19 03:14:07 UTC). This will send
>> hrtimer_interrupt into an infinite loop on some architectures (arm),
>> or emit an oops on others(x86).
> If we really want to survive 2038, then we need to get rid of the
> timespec based representation of time in the kernel alltogether and
> switch all related code over to a scalar nsec 64bit storage.
>
> Just "fixing" some random parts of the code in a "make it work
> somehow" way is a pointless exercise IMO.
>
> We already had long discussions about how the timekeeping code should
> be restructured to address that and other problems at least on the
> kernel side and switching everything to scalar storage is definitely
> the way to go.
>
> Though even if we fix that we still need to twist our brains around
> the timespec/timeval based user space interfaces. That's going to be
> the way more interesting challenge.

So yea.. there's a couple approaches for userland that probably need 
more discussion:

1) Create a new ABI for 32bit platforms that have a 64bit time_t
     - I know x32 was talking about this, but I don't actually see that 
code upstream, so maybe there was an issue that blocked this?
     - In talking with some folks, there was some question on how to 
handle multiple compat types, so a 64bit OS could support both old and 
new 32bit abis. I suspect there's some approach that would work here, 
but haven't done any research.

2) Add new time64_t/timespec64 structures, and add new 64bit versions of 
syscalls for any syscall that takes a timespec/time_t
     - This is a ton of work, and lots of new syscalls. Yuck.

3) Redefine time_t to be unsigned. (Possibly as part of an abi bump?). 
This is attractive, as it requires the least change to the kernel 
interfaces, and in many cases existing userland won't care (there' no 
userland that's setting timers for dates prior to 1970). We'd just need 
to update the libc ascii time formatting, and basically give up dates 
prior to 1970. Of course, this is probably too optimistic as existing 
userland code that does (time_a < time_b) would have issues comparing 
dates before and after the 2038 overflow. However, those apps will be 
broken no matter what, so I'm starting to think this approach is likely 
to be the most reasonable.


I'm curious if there are any there other ideas that folks are considering?

thanks
-john

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