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]

Date:	Wed, 07 Oct 2015 15:47:19 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Miroslav Lichvar <mlichvar@...hat.com>
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 Wednesday 07 October 2015 15:22:17 Miroslav Lichvar wrote:
> On systems with 32-bit time_t there are quite a few problems that
> applications may have with time overflowing in year 2038. Beside getting
> to an unexpected state by not checking integer operations with time_t
> variables, some system calls have unexpected behavior, e.g. the system
> time can't be set back to the current time (negative value), timers with
> the ABSTIME flag can't be set (negative value) or they expire
> immediately (current time is always larger).
> 
> It would be unrealistic to expect all applications to be able to handle
> all these problems. Year 2038 is still many years away, but this can be
> a problem even now. The clock can get close to the overflow accidentally
> or maliciously, e.g. when it is synchronized over network by NTP or PTP.
> 
> 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.
> 
> A new kernel sysctl time_max is added to select the maximum time. It can
> be set to 0 for no limit, 1 for one week before 32-bit time_t overflow,
> and 2 for one week before ktime_t overflow. The default value is 1 with
> 32-bit time_t and 2 with 64-bit time_t. This can be changed later to be
> always 2 when 64-bit versions of system calls working with time_t are
> available.

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

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.

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