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]

Message-ID: <alpine.LFD.2.02.1306072248430.24812@ionos>
Date:	Fri, 7 Jun 2013 22:57:18 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Tobias Waldekranz <tobias@...dekranz.com>
cc:	LKML <linux-kernel@...r.kernel.org>,
	John Stultz <john.stultz@...aro.org>,
	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH] timekeeping: handle epoch roll-over (2038) on 32-bit
 systems

Tobias,

On Tue, 4 Jun 2013, Tobias Waldekranz wrote:
> On Mon, Jun 03, 2013 at 04:34:25PM +0200, Thomas Gleixner wrote:
> > Just "fixing" some random parts of the code in a "make it work
> > somehow" way is a pointless exercise IMO.
> > 
> Now hold on, it is hardly random. On an ARM system, the kernel will
> completely hang. I would think that many users would like to avoid
> that. In addition this behavior is rather new, hrtimer_interrupt used
> to source its time from ktime_get which avoids this issue. The change
> was introduced in:
> 
> 5baefd6d84163443215f4a99f6a20f054ef11236
> 
> I understand that you would like a solution to the broader issue. But
> for some users (embedded especially) having a system that continues to
> operate 25 years from now is an issue today.
> 
> As for "make it work somehow", modifying the current time calculation
> to work in the same way as in ktime_get does seem to be a reasonable
> way to go IMO.

No, it's not. You are "fixing" something which is not fixable by
definition. There is no rule to prevent similar borkage tomorrow.

You are just band aiding a singular instance of a massive problem
which has an already known root cause.

If you really care about your system working in 25 years from now with
the kernel of today then you rather should sit down and fix it proper.

Your "fix" merily allows the system to boot, but its broken beyond
repair aside of that. So what's the point?

If we do not tackle the underlying issues, then your machine will be
rendered completely useless with or without your patch. It's that
simple. So don't try to sell me a bandaid hack as a reasonable way to
go.

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/