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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.02.1306072308040.24812@ionos>
Date:	Fri, 7 Jun 2013 23:53:23 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	John Stultz <john.stultz@...aro.org>
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 Mon, 3 Jun 2013, John Stultz wrote:
> On 06/03/2013 07:34 AM, Thomas Gleixner wrote:
> > 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.
> 
> I'm curious if there are any there other ideas that folks are considering?

Honestly, we have almost 25 years ahead of us to solve that. So why
hurry? If Tobias thinks that his embedded system of today needs to
survive 2038 without updating the kernel and all of userspace, then
all I can do is wish him good luck. Albeit we should not waste 25
years and run into another Y2K horror. :)

The only solid solution is to implement a new set of syscalls (and
there are not that many which are affected by this). The new syscalls
should use a nanosecond based scalar time value and get rid of the
timespec /timeval / time_t nonsense alltogether. That reduces the
number of new syscalls significantly.

That time value should be 64bit, also people might argue, that we are
creating a new issue for the year 2554, i.e 541 years from now. I
don't think we need to worry about that really. We have to leave our
grand-grand-grand..grandchildren (~20 generations from now) a few
unsolved problems!

The evil plan to make this happen looks like this:

    1) Convert the core code to u64 with a timespec based shadow
       infrastruture to avoid performance regressions in the first
       place.

    2) Add new u64 based syscalls

    3) Disable the timespec based shadow infrastructure five years
       from now to force all lazy buggers who ignored the new syscalls
       to fix their crap.

    4) Deprecate the old syscalls 10 years from now

    5) Remove the old syscalls 100 years from now so Linus won't hunt
       us for breaking userspace :)

Thanks,

	tglx

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