linux-kernel - Re: [PATCH] timekeeping: Limit system time to prevent 32-bit time

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: <20151007142343.GM5778@localhost>
Date:	Wed, 7 Oct 2015 16:23:44 +0200
From:	Miroslav Lichvar <mlichvar@...hat.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	linux-kernel@...r.kernel.org, y2038@...ts.linaro.org,
	John Stultz <john.stultz@...aro.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Prarit Bhargava <prarit@...hat.com>,
	Richard Cochran <richardcochran@...il.com>
Subject: Re: [PATCH] timekeeping: Limit system time to prevent 32-bit time_t
 overflow

On Wed, Oct 07, 2015 at 03:47:19PM +0200, Arnd Bergmann wrote:
> On Wednesday 07 October 2015 15:22:17 Miroslav Lichvar wrote:
> > This patch sets a maximum value of the system time to prevent the system
> > time from getting too close to the overflow. The time can't be set to a
> > larger value. When the maximum is reached in normal time accumulation,
> > the clock will be stepped back by one week.
> 
> I can't see whether this is really a good idea: moving the time backwards
> will break all sorts of drivers that (incorrectly) expect the real
> time clock to have monotonic behavior, and quite often, file timestamps

Well, do these drivers break when the clock is stepped back by ntpd?
Maybe it would be better to fix them.

> are expected to be in the past in user space. A common example is
> 'make', which goes nuts when it sees files in the future.

Without the limit added by this patch make will go nuts just one week
later when the 32-bit time_t overflows to Dec 13 1901 and the files
will appear as 136 years in the future. How is that better?

> So for all I can tell, your patch only replaces one set of problems
> that happens at the time of the overflow with a different set of problems.

I think it converts a set of problems that are difficult to handle and
most people don't even know about to a single well known problem
(clock being stepped back).

I'd suggest to run "date -s @$[2**31 - 20]" on a 32-bit system and try
working in that.

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