Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932888AbbDIRFQ (ORCPT ); Thu, 9 Apr 2015 13:05:16 -0400 Received: from mail-ig0-f180.google.com ([209.85.213.180]:38881 "EHLO mail-ig0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753847AbbDIRFN (ORCPT ); Thu, 9 Apr 2015 13:05:13 -0400 MIME-Version: 1.0 In-Reply-To: <20150409164548.GP32271@localhost> References: <20150409164548.GP32271@localhost> Date: Thu, 9 Apr 2015 10:05:13 -0700 Message-ID: Subject: Re: Preventing 32-bit time_t overflow From: John Stultz To: Miroslav Lichvar Cc: lkml , Thomas Gleixner , Prarit Bhargava , Richard Cochran , Arnd Bergmann Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3411 Lines: 68 On Thu, Apr 9, 2015 at 9:45 AM, Miroslav Lichvar 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/