Message-ID: <CALAqxLXoOBgAd76qvhW4tzMYauhJwewAU0LRWxKRHQZAtehVzQ@mail.gmail.com>
Date:	Thu, 9 Apr 2015 10:05:13 -0700
From:	John Stultz <john.stultz@...aro.org>
To:	Miroslav Lichvar <mlichvar@...hat.com>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Prarit Bhargava <prarit@...hat.com>,
	Richard Cochran <richardcochran@...il.com>,
	Arnd Bergmann <arnd@...db.de>
Subject: Re: Preventing 32-bit time_t overflow

On Thu, Apr 9, 2015 at 9:45 AM, Miroslav Lichvar <mlichvar@...hat.com> wrote:
> I did a test to see what happens on a system when 32-bit time_t
> overflows. While the kernel seems to continue running without big
> problems and it's possible to set the clock back to a time before the
> overflow, some applications are not so good, they are burning CPU, the
> system log is getting filled, it looks like an admin's nightmare.
>
> I'm not sure how many of them are bugs in math with time_t and how
> many are due to unexpected results from system calls like setting
> timers with the ABSTIME flag to time before 1970, but I think it would
> be pretty unrealistic to expect all applications to be able to handle
> all the problems that can happen when time_t overflows or is close to
> the overflow.

Yea. The kernel used to hang fairly solid on overflow before 3.17 (on
32bit systems, of course), but we're trying to address the 2038 issue
by converting all in-kernel users from time_t to time64_t. There's
still quite a bit to do, but its slow going to make sure we don't
break anything in the process.

Then its a matter of adding time64_t based syscalls that 32bit
applications can be recompiled to use.

As for userland issues you've seen, I suspect you're right that the
applications are trying to set timers after time_t goes negative and
are spinning trying to get it set when it returns EINVAL.

As we get closer to the real date, if getting applications properly
fixed continues to be an issue, we might want to look at treating
32bit timer values as unsigned in the kernel, but there's so many ways
the application could still be broken, the real fix is to convert it
to using a 64bit time structure.

> The trouble is this can be exploited with unauthenticated NTP or PTP.
> With a spoofed reply the clock can be set close to the overflow. Some
> NTP/PTP implementations don't allow (large) steps after the initial
> synchronization, so a system that's already running with good time
> might be safe, but there are some implementations where the clock can
> be set to any value at any time. Also, a lot of people are running
> ntpdate or similar from cron.
>
> I'm wondering if this is something that would make sense to address
> in the kernel, at least for now.
>
> I was thinking about reserving an interval (e.g. month or year) before
> the overflow where the time would be considered invalid and the clock
> couldn't be set to it. In the time accumulation would be a check
> if the time is still valid and if not, the clock would be set back by
> day, month or year as if adjtimex(ADJ_SETOFFSET) was called, so the
> overflow never actually happens and there is always some room for
> calculations around current time. It could be configurable, to allow
> people to test the kernel and applications for the overflow.
>
> What do you think?

Yea, at some point the restrictions would have to be lifted, but while
we are in-process of addressing this, your suggestion makes sense.
Though having malicious ntp servers result in more subtle effects is
probably also an admin nightmare, so I'm not sure if its really
providing much relief. :)

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/

Powered by blists - more mailing lists