Re: [PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

2015-10-09 Thread Miroslav Lichvar 
On Fri, Oct 09, 2015 at 12:38:32PM +0200, Thomas Gleixner wrote:
> On Fri, 9 Oct 2015, Miroslav Lichvar wrote:
> > Do you feel the same about preventing the time from reaching
> > KTIME_MAX?
> 
> That's going to happen in ~500 years from now.

At any time if you include accidents and attacks on services with
the CAP_SYS_TIME capability (e.g. NTP/PTP implementations). Even with
32-bit time_t you are not safe, the time can be set forward by any
amount with multiple adjtimex(ADJ_SETOFFSET) calls.

-- 
Miroslav Lichvar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

2015-10-09 Thread Thomas Gleixner 
On Fri, 9 Oct 2015, Miroslav Lichvar wrote:
> On Fri, Oct 09, 2015 at 10:46:16AM +0100, Thomas Gleixner wrote:
> > On Thu, 8 Oct 2015, Miroslav Lichvar wrote:
> > > Applications are not allowed to rely on system time being sane?
> > > To me the current behavior looks like the kernel is throwing the
> > > applications off a cliff, while it's the only thing that can fly :).
> > 
> > As Arnd said, you are creating a wrong sense of safety. They fall off
> > the cliff with your changes as well. The fall is just different. Think
> > about timeouts, user space overflows of time_t etc.
> 
> I think vast majority of them won't fall. It doesn't prevent all
> problems, but at least the userspace agrees with kernel on what the
> current time it is, that looks to me like the most difficult one to
> fix in applications.
> 
> > We need to fix all of it, no matter what.
> 
> Yeah, that would be nice, but I don't think it's realistic.
> 
> Do you feel the same about preventing the time from reaching
> KTIME_MAX?

That's going to happen in ~500 years from now.

Thanks,

tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

2015-10-09 Thread Miroslav Lichvar 
On Fri, Oct 09, 2015 at 10:46:16AM +0100, Thomas Gleixner wrote:
> On Thu, 8 Oct 2015, Miroslav Lichvar wrote:
> > Applications are not allowed to rely on system time being sane?
> > To me the current behavior looks like the kernel is throwing the
> > applications off a cliff, while it's the only thing that can fly :).
> 
> As Arnd said, you are creating a wrong sense of safety. They fall off
> the cliff with your changes as well. The fall is just different. Think
> about timeouts, user space overflows of time_t etc.

I think vast majority of them won't fall. It doesn't prevent all
problems, but at least the userspace agrees with kernel on what the
current time it is, that looks to me like the most difficult one to
fix in applications.

> We need to fix all of it, no matter what.

Yeah, that would be nice, but I don't think it's realistic.

Do you feel the same about preventing the time from reaching
KTIME_MAX?

-- 
Miroslav Lichvar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

2015-10-09 Thread Thomas Gleixner 
On Thu, 8 Oct 2015, Miroslav Lichvar wrote:
> On Thu, Oct 08, 2015 at 10:52:05AM +0200, Arnd Bergmann wrote:
> > On Thursday 08 October 2015 08:23:44 Miroslav Lichvar wrote:
> > > The difference is that with the one-week step the kernel and userspace
> > > still agree on the current time and it is always valid from the kernel
> > > point of view, absolute timers can be set, etc.
> > 
> > Ok, I can see that as an improvement, but it still seems to give
> > a false sense of safety, and I feel we really should not have any code
> > rely on this behavior.
> 
> Applications are not allowed to rely on system time being sane?
> To me the current behavior looks like the kernel is throwing the
> applications off a cliff, while it's the only thing that can fly :).

As Arnd said, you are creating a wrong sense of safety. They fall off
the cliff with your changes as well. The fall is just different. Think
about timeouts, user space overflows of time_t etc.

We need to fix all of it, no matter what.

Thanks,

tglx




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

2015-10-09 Thread Thomas Gleixner 
On Thu, 8 Oct 2015, Miroslav Lichvar wrote:
> On Thu, Oct 08, 2015 at 10:52:05AM +0200, Arnd Bergmann wrote:
> > On Thursday 08 October 2015 08:23:44 Miroslav Lichvar wrote:
> > > The difference is that with the one-week step the kernel and userspace
> > > still agree on the current time and it is always valid from the kernel
> > > point of view, absolute timers can be set, etc.
> > 
> > Ok, I can see that as an improvement, but it still seems to give
> > a false sense of safety, and I feel we really should not have any code
> > rely on this behavior.
> 
> Applications are not allowed to rely on system time being sane?
> To me the current behavior looks like the kernel is throwing the
> applications off a cliff, while it's the only thing that can fly :).

As Arnd said, you are creating a wrong sense of safety. They fall off
the cliff with your changes as well. The fall is just different. Think
about timeouts, user space overflows of time_t etc.

We need to fix all of it, no matter what.

Thanks,

tglx




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

2015-10-09 Thread Thomas Gleixner 
On Fri, 9 Oct 2015, Miroslav Lichvar wrote:
> On Fri, Oct 09, 2015 at 10:46:16AM +0100, Thomas Gleixner wrote:
> > On Thu, 8 Oct 2015, Miroslav Lichvar wrote:
> > > Applications are not allowed to rely on system time being sane?
> > > To me the current behavior looks like the kernel is throwing the
> > > applications off a cliff, while it's the only thing that can fly :).
> > 
> > As Arnd said, you are creating a wrong sense of safety. They fall off
> > the cliff with your changes as well. The fall is just different. Think
> > about timeouts, user space overflows of time_t etc.
> 
> I think vast majority of them won't fall. It doesn't prevent all
> problems, but at least the userspace agrees with kernel on what the
> current time it is, that looks to me like the most difficult one to
> fix in applications.
> 
> > We need to fix all of it, no matter what.
> 
> Yeah, that would be nice, but I don't think it's realistic.
> 
> Do you feel the same about preventing the time from reaching
> KTIME_MAX?

That's going to happen in ~500 years from now.

Thanks,

tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

2015-10-09 Thread Miroslav Lichvar 
On Fri, Oct 09, 2015 at 12:38:32PM +0200, Thomas Gleixner wrote:
> On Fri, 9 Oct 2015, Miroslav Lichvar wrote:
> > Do you feel the same about preventing the time from reaching
> > KTIME_MAX?
> 
> That's going to happen in ~500 years from now.

At any time if you include accidents and attacks on services with
the CAP_SYS_TIME capability (e.g. NTP/PTP implementations). Even with
32-bit time_t you are not safe, the time can be set forward by any
amount with multiple adjtimex(ADJ_SETOFFSET) calls.

-- 
Miroslav Lichvar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

2015-10-09 Thread Miroslav Lichvar 
On Fri, Oct 09, 2015 at 10:46:16AM +0100, Thomas Gleixner wrote:
> On Thu, 8 Oct 2015, Miroslav Lichvar wrote:
> > Applications are not allowed to rely on system time being sane?
> > To me the current behavior looks like the kernel is throwing the
> > applications off a cliff, while it's the only thing that can fly :).
> 
> As Arnd said, you are creating a wrong sense of safety. They fall off
> the cliff with your changes as well. The fall is just different. Think
> about timeouts, user space overflows of time_t etc.

I think vast majority of them won't fall. It doesn't prevent all
problems, but at least the userspace agrees with kernel on what the
current time it is, that looks to me like the most difficult one to
fix in applications.

> We need to fix all of it, no matter what.

Yeah, that would be nice, but I don't think it's realistic.

Do you feel the same about preventing the time from reaching
KTIME_MAX?

-- 
Miroslav Lichvar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

2015-10-08 Thread Miroslav Lichvar 
On Thu, Oct 08, 2015 at 10:52:05AM +0200, Arnd Bergmann wrote:
> On Thursday 08 October 2015 08:23:44 Miroslav Lichvar wrote:
> > The difference is that with the one-week step the kernel and userspace
> > still agree on the current time and it is always valid from the kernel
> > point of view, absolute timers can be set, etc.
> 
> Ok, I can see that as an improvement, but it still seems to give
> a false sense of safety, and I feel we really should not have any code
> rely on this behavior.

Applications are not allowed to rely on system time being sane?
To me the current behavior looks like the kernel is throwing the
applications off a cliff, while it's the only thing that can fly :).

-- 
Miroslav Lichvar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

2015-10-08 Thread Arnd Bergmann 
On Thursday 08 October 2015 08:23:44 Miroslav Lichvar wrote:
> On Wed, Oct 07, 2015 at 05:10:34PM +0200, Arnd Bergmann wrote:
> > On Wednesday 07 October 2015 16:23:44 Miroslav Lichvar wrote:
> > > 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?
> > 
> > Not better or worse at all, that was my point. The time is still
> > wrong either way, whether you step back by a week or 136 years.
> 
> The difference is that with the one-week step the kernel and userspace
> still agree on the current time and it is always valid from the kernel
> point of view, absolute timers can be set, etc.

Ok, I can see that as an improvement, but it still seems to give
a false sense of safety, and I feel we really should not have any code
rely on this behavior.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

2015-10-08 Thread Miroslav Lichvar 
On Wed, Oct 07, 2015 at 05:10:34PM +0200, Arnd Bergmann wrote:
> On Wednesday 07 October 2015 16:23:44 Miroslav Lichvar wrote:
> > 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?
> 
> Not better or worse at all, that was my point. The time is still
> wrong either way, whether you step back by a week or 136 years.

The difference is that with the one-week step the kernel and userspace
still agree on the current time and it is always valid from the kernel
point of view, absolute timers can be set, etc.

-- 
Miroslav Lichvar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

2015-10-08 Thread Miroslav Lichvar 
On Wed, Oct 07, 2015 at 05:10:34PM +0200, Arnd Bergmann wrote:
> On Wednesday 07 October 2015 16:23:44 Miroslav Lichvar wrote:
> > 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?
> 
> Not better or worse at all, that was my point. The time is still
> wrong either way, whether you step back by a week or 136 years.

The difference is that with the one-week step the kernel and userspace
still agree on the current time and it is always valid from the kernel
point of view, absolute timers can be set, etc.

-- 
Miroslav Lichvar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

2015-10-08 Thread Arnd Bergmann 
On Thursday 08 October 2015 08:23:44 Miroslav Lichvar wrote:
> On Wed, Oct 07, 2015 at 05:10:34PM +0200, Arnd Bergmann wrote:
> > On Wednesday 07 October 2015 16:23:44 Miroslav Lichvar wrote:
> > > 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?
> > 
> > Not better or worse at all, that was my point. The time is still
> > wrong either way, whether you step back by a week or 136 years.
> 
> The difference is that with the one-week step the kernel and userspace
> still agree on the current time and it is always valid from the kernel
> point of view, absolute timers can be set, etc.

Ok, I can see that as an improvement, but it still seems to give
a false sense of safety, and I feel we really should not have any code
rely on this behavior.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

2015-10-08 Thread Miroslav Lichvar 
On Thu, Oct 08, 2015 at 10:52:05AM +0200, Arnd Bergmann wrote:
> On Thursday 08 October 2015 08:23:44 Miroslav Lichvar wrote:
> > The difference is that with the one-week step the kernel and userspace
> > still agree on the current time and it is always valid from the kernel
> > point of view, absolute timers can be set, etc.
> 
> Ok, I can see that as an improvement, but it still seems to give
> a false sense of safety, and I feel we really should not have any code
> rely on this behavior.

Applications are not allowed to rely on system time being sane?
To me the current behavior looks like the kernel is throwing the
applications off a cliff, while it's the only thing that can fly :).

-- 
Miroslav Lichvar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

2015-10-07 Thread Arnd Bergmann 
On Wednesday 07 October 2015 16:23:44 Miroslav Lichvar wrote:
> 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?

Yes.

> Maybe it would be better to fix them.

We are in the process of doing that: All drivers that currently use
do_gettimeofday() or get_seconds() are being audited and converted
to one of ktime_get(), ktime_get_real(), ktime_get_ts64(),
ktime_get_real_ts64(), ktime_get_seconds() or ktime_get_real_seconds().

The 'real' versions should only be used when the driver wants to know
the wallclock but is ok with time going backwards.

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

Not better or worse at all, that was my point. The time is still
wrong either way, whether you step back by a week or 136 years.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

2015-10-07 Thread Miroslav Lichvar 
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

2015-10-07 Thread Arnd Bergmann 
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

2015-10-07 Thread Miroslav Lichvar 
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.

Cc: John Stultz 
Cc: Thomas Gleixner 
Cc: Prarit Bhargava 
Cc: Richard Cochran 
Cc: Arnd Bergmann 
Signed-off-by: Miroslav Lichvar 
---

v2: - optimized code in accumulate_nsecs_to_secs() a bit
- improved log message and increased its level to warning

 Documentation/sysctl/kernel.txt | 19 
 include/linux/timekeeping.h |  5 
 include/uapi/linux/sysctl.h |  1 +
 kernel/sysctl.c |  9 ++
 kernel/sysctl_binary.c  |  1 +
 kernel/time/timekeeping.c   | 64 +
 6 files changed, 93 insertions(+), 6 deletions(-)

diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index 6fccb69..9b2bbdd 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -83,6 +83,7 @@ show up in /proc/sys/kernel:
 - sysctl_writes_strict
 - tainted
 - threads-max
+- time_max
 - unknown_nmi_panic
 - watchdog
 - watchdog_thresh
@@ -893,6 +894,24 @@ available RAM pages threads-max is reduced accordingly.
 
 ==
 
+time_max:
+
+Select the maximum allowed value of the system time. The system clock cannot be
+set to a larger value and when it reaches the maximum on its own, it will be
+stepped back by one week.
+
+0: No limit.
+
+1: One week before 32-bit time_t overflows, i.e. Jan 12 03:14:07 UTC 2038.
+   This is currently the default value with 32-bit time_t, but it may change
+   when 64-bit versions of system calls working with time_t are available.
+
+2: One week before time in the internal kernel representation (ktime_t)
+   overflows, i.e. Apr 4 23:47:16 UTC 2262. This is the default value with
+   64-bit time_t.
+
+==
+
 unknown_nmi_panic:
 
 The value in this file affects behavior of handling NMI. When the
diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
index ba0ae09..f25df65 100644
--- a/include/linux/timekeeping.h
+++ b/include/linux/timekeeping.h
@@ -5,6 +5,11 @@
 
 void timekeeping_init(void);
 extern int timekeeping_suspended;
+extern int sysctl_time_max;
+
+struct ctl_table;
+extern int sysctl_time_max_handler(struct ctl_table *table, int write,
+   void __user *buffer, size_t *length, loff_t *ppos);
 
 /*
  * Get and set timeofday
diff --git a/include/uapi/linux/sysctl.h b/include/uapi/linux/sysctl.h
index 0956373..8fd2aab 100644
--- a/include/uapi/linux/sysctl.h
+++ b/include/uapi/linux/sysctl.h
@@ -154,6 +154,7 @@ enum
KERN_NMI_WATCHDOG=75, /* int: enable/disable nmi watchdog */
KERN_PANIC_ON_NMI=76, /* int: whether we will panic on an unrecovered */
KERN_PANIC_ON_WARN=77, /* int: call panic() in WARN() functions */
+   KERN_TIMEMAX=78,/* int: select maximum allowed system time */
 };
 
 
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index e69201d..c2cfb33 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -1130,6 +1130,15 @@ static struct ctl_table kern_table[] = {
.extra1 = ,
.extra2 = ,
},
+   {
+   .procname   = "time_max",
+   .data   = _time_max,
+   .maxlen = sizeof(int),
+   .mode   = 0644,
+   .proc_handler   = sysctl_time_max_handler,
+   .extra1 = ,
+   .extra2 = ,
+   },
 #if defined(CONFIG_SMP) && defined(CONFIG_NO_HZ_COMMON)
{
.procname   = "timer_migration",
diff --git a/kernel/sysctl_binary.c

[PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

2015-10-07 Thread Miroslav Lichvar 
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.

Cc: John Stultz 
Cc: Thomas Gleixner 
Cc: Prarit Bhargava 
Cc: Richard Cochran 
Cc: Arnd Bergmann 
Signed-off-by: Miroslav Lichvar 
---

v2: - optimized code in accumulate_nsecs_to_secs() a bit
- improved log message and increased its level to warning

 Documentation/sysctl/kernel.txt | 19 
 include/linux/timekeeping.h |  5 
 include/uapi/linux/sysctl.h |  1 +
 kernel/sysctl.c |  9 ++
 kernel/sysctl_binary.c  |  1 +
 kernel/time/timekeeping.c   | 64 +
 6 files changed, 93 insertions(+), 6 deletions(-)

diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index 6fccb69..9b2bbdd 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -83,6 +83,7 @@ show up in /proc/sys/kernel:
 - sysctl_writes_strict
 - tainted
 - threads-max
+- time_max
 - unknown_nmi_panic
 - watchdog
 - watchdog_thresh
@@ -893,6 +894,24 @@ available RAM pages threads-max is reduced accordingly.
 
 ==
 
+time_max:
+
+Select the maximum allowed value of the system time. The system clock cannot be
+set to a larger value and when it reaches the maximum on its own, it will be
+stepped back by one week.
+
+0: No limit.
+
+1: One week before 32-bit time_t overflows, i.e. Jan 12 03:14:07 UTC 2038.
+   This is currently the default value with 32-bit time_t, but it may change
+   when 64-bit versions of system calls working with time_t are available.
+
+2: One week before time in the internal kernel representation (ktime_t)
+   overflows, i.e. Apr 4 23:47:16 UTC 2262. This is the default value with
+   64-bit time_t.
+
+==
+
 unknown_nmi_panic:
 
 The value in this file affects behavior of handling NMI. When the
diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
index ba0ae09..f25df65 100644
--- a/include/linux/timekeeping.h
+++ b/include/linux/timekeeping.h
@@ -5,6 +5,11 @@
 
 void timekeeping_init(void);
 extern int timekeeping_suspended;
+extern int sysctl_time_max;
+
+struct ctl_table;
+extern int sysctl_time_max_handler(struct ctl_table *table, int write,
+   void __user *buffer, size_t *length, loff_t *ppos);
 
 /*
  * Get and set timeofday
diff --git a/include/uapi/linux/sysctl.h b/include/uapi/linux/sysctl.h
index 0956373..8fd2aab 100644
--- a/include/uapi/linux/sysctl.h
+++ b/include/uapi/linux/sysctl.h
@@ -154,6 +154,7 @@ enum
KERN_NMI_WATCHDOG=75, /* int: enable/disable nmi watchdog */
KERN_PANIC_ON_NMI=76, /* int: whether we will panic on an unrecovered */
KERN_PANIC_ON_WARN=77, /* int: call panic() in WARN() functions */
+   KERN_TIMEMAX=78,/* int: select maximum allowed system time */
 };
 
 
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index e69201d..c2cfb33 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -1130,6 +1130,15 @@ static struct ctl_table kern_table[] = {
.extra1 = ,
.extra2 = ,
},
+   {
+   .procname   = "time_max",
+   .data   = _time_max,
+   .maxlen = sizeof(int),
+   .mode   = 0644,
+   .proc_handler   = sysctl_time_max_handler,
+   .extra1 = ,
+   .extra2 = ,
+   },
 #if defined(CONFIG_SMP) &&

Re: [PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

2015-10-07 Thread Arnd Bergmann 
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

2015-10-07 Thread Arnd Bergmann 
On Wednesday 07 October 2015 16:23:44 Miroslav Lichvar wrote:
> 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?

Yes.

> Maybe it would be better to fix them.

We are in the process of doing that: All drivers that currently use
do_gettimeofday() or get_seconds() are being audited and converted
to one of ktime_get(), ktime_get_real(), ktime_get_ts64(),
ktime_get_real_ts64(), ktime_get_seconds() or ktime_get_real_seconds().

The 'real' versions should only be used when the driver wants to know
the wallclock but is ok with time going backwards.

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

Not better or worse at all, that was my point. The time is still
wrong either way, whether you step back by a week or 136 years.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

2015-10-07 Thread Miroslav Lichvar 
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

2015-04-16 Thread Miroslav Lichvar 
On Wed, Apr 15, 2015 at 12:17:36PM -0400, Justin Keller wrote:
> Is there a reason for "step = leap"?

It's there to not change the behavior when a leap second occurs, the
clock still needs to be stepped. I guess it could be optimized a bit,
if it used "if (unlikely(leap || tk->xtime_sec >= time_max_sec))", the
64-bit step variable wouldn't have to be used in normal operation.

> > /* Figure out if its a leap sec and apply if needed */
> > leap = second_overflow(tk->xtime_sec);
> > -   if (unlikely(leap)) {
> > +   step = leap;
> > +
> > +   /* If the system time reached the maximum, step it back */
> > +   if (unlikely(tk->xtime_sec >= time_max_sec)) {
> > +   step = time_max_sec - tk->xtime_sec - SEC_PER_WEEK;
> > +   printk(KERN_NOTICE
> > +   "Clock: maximum time reached, stepping 
> > back\n");
> > +   }
> > +
> > +   if (unlikely(step)) {
> > struct timespec64 ts;
> >
> > -   tk->xtime_sec += leap;
> > +   tk->xtime_sec += step;

-- 
Miroslav Lichvar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

2015-04-16 Thread Miroslav Lichvar 
On Wed, Apr 15, 2015 at 10:31:54PM +0100, One Thousand Gnomes wrote:
> On Wed, 15 Apr 2015 17:41:28 +0200
> Miroslav Lichvar  wrote:
> > larger value. When the maximum is reached in normal time accumulation,
> > the clock will be stepped back by one week.
> 
> Which itself is open to exploits and dirty tricks and causes bizarre
> problems.

Any examples? I think it shouldn't be any worse than having system
clock with incorrect time and making a backward step, which is a well
understood problem.

> IMHO it doesn't actually improve the situation.

Do you have a 32-bit system for testing? Try "date -s @2147483600",
wait one minute and see if it's not worth preventing.

I think the power consumption alone is worth it. If there is some
widely used application/service in which the overflow triggers an
infinite loop making requests to a network service, maybe it could
prevent a DDoS attack.

-- 
Miroslav Lichvar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

2015-04-16 Thread Miroslav Lichvar 
On Wed, Apr 15, 2015 at 10:31:54PM +0100, One Thousand Gnomes wrote:
 On Wed, 15 Apr 2015 17:41:28 +0200
 Miroslav Lichvar mlich...@redhat.com wrote:
  larger value. When the maximum is reached in normal time accumulation,
  the clock will be stepped back by one week.
 
 Which itself is open to exploits and dirty tricks and causes bizarre
 problems.

Any examples? I think it shouldn't be any worse than having system
clock with incorrect time and making a backward step, which is a well
understood problem.

 IMHO it doesn't actually improve the situation.

Do you have a 32-bit system for testing? Try date -s @2147483600,
wait one minute and see if it's not worth preventing.

I think the power consumption alone is worth it. If there is some
widely used application/service in which the overflow triggers an
infinite loop making requests to a network service, maybe it could
prevent a DDoS attack.

-- 
Miroslav Lichvar
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

2015-04-16 Thread Miroslav Lichvar 
On Wed, Apr 15, 2015 at 12:17:36PM -0400, Justin Keller wrote:
 Is there a reason for step = leap?

It's there to not change the behavior when a leap second occurs, the
clock still needs to be stepped. I guess it could be optimized a bit,
if it used if (unlikely(leap || tk-xtime_sec = time_max_sec)), the
64-bit step variable wouldn't have to be used in normal operation.

  /* Figure out if its a leap sec and apply if needed */
  leap = second_overflow(tk-xtime_sec);
  -   if (unlikely(leap)) {
  +   step = leap;
  +
  +   /* If the system time reached the maximum, step it back */
  +   if (unlikely(tk-xtime_sec = time_max_sec)) {
  +   step = time_max_sec - tk-xtime_sec - SEC_PER_WEEK;
  +   printk(KERN_NOTICE
  +   Clock: maximum time reached, stepping 
  back\n);
  +   }
  +
  +   if (unlikely(step)) {
  struct timespec64 ts;
 
  -   tk-xtime_sec += leap;
  +   tk-xtime_sec += step;

-- 
Miroslav Lichvar
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

2015-04-15 Thread One Thousand Gnomes 
On Wed, 15 Apr 2015 17:41:28 +0200
Miroslav Lichvar  wrote:

> On systems with 32-bit time_t, it seems there are quite a few problems
> that applications may have with time overflowing in year 2038. Beside

Even ext4 is still broken for 2038.

> larger value. When the maximum is reached in normal time accumulation,
> the clock will be stepped back by one week.

Which itself is open to exploits and dirty tricks and causes bizarre
problems. IMHO it doesn't actually improve the situation.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

2015-04-15 Thread Justin Keller 
Is there a reason for "step = leap"?
On Wed, Apr 15, 2015 at 11:41 AM, Miroslav Lichvar  wrote:
> On systems with 32-bit time_t, it seems there are quite a few problems
> that applications may have with time overflowing in year 2038. Beside
> getting in 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 be set close to the overflow
> accidentally or maliciously, e.g. when the clock 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 using 32-bit time_t are
> available.
>
> Signed-off-by: Miroslav Lichvar 
> ---
>  Documentation/sysctl/kernel.txt | 19 +
>  include/linux/timekeeping.h |  5 
>  include/uapi/linux/sysctl.h |  1 +
>  kernel/sysctl.c |  9 ++
>  kernel/sysctl_binary.c  |  1 +
>  kernel/time/timekeeping.c   | 62 
> +
>  6 files changed, 91 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
> index 83ab256..08e4f28 100644
> --- a/Documentation/sysctl/kernel.txt
> +++ b/Documentation/sysctl/kernel.txt
> @@ -82,6 +82,7 @@ show up in /proc/sys/kernel:
>  - sysctl_writes_strict
>  - tainted
>  - threads-max
> +- time_max
>  - unknown_nmi_panic
>  - watchdog_thresh
>  - version
> @@ -847,6 +848,24 @@ can be ORed together:
>
>  ==
>
> +time_max:
> +
> +Select the maximum allowed value of the system time. The system clock cannot 
> be
> +set to a larger value and when it reaches the maximum on its own, it will be
> +stepped back by one week.
> +
> +0: No limit.
> +
> +1: One week before 32-bit time_t overflows, i.e. Jan 12 03:14:07 UTC 2038.
> +   This is currently the default value with 32-bit time_t, but it will likely
> +   change when 64-bit versions of system calls using time_t are available.
> +
> +2: One week before time in the internal kernel representation (ktime_t)
> +   overflows, i.e. Apr 4 23:47:16 UTC 2262. This is the default value with
> +   64-bit time_t.
> +
> +==
> +
>  unknown_nmi_panic:
>
>  The value in this file affects behavior of handling NMI. When the
> diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
> index 99176af..51fc970 100644
> --- a/include/linux/timekeeping.h
> +++ b/include/linux/timekeeping.h
> @@ -5,6 +5,11 @@
>
>  void timekeeping_init(void);
>  extern int timekeeping_suspended;
> +extern int sysctl_time_max;
> +
> +struct ctl_table;
> +extern int sysctl_time_max_handler(struct ctl_table *table, int write,
> +   void __user *buffer, size_t *length, loff_t *ppos);
>
>  /*
>   * Get and set timeofday
> diff --git a/include/uapi/linux/sysctl.h b/include/uapi/linux/sysctl.h
> index 0956373..8fd2aab 100644
> --- a/include/uapi/linux/sysctl.h
> +++ b/include/uapi/linux/sysctl.h
> @@ -154,6 +154,7 @@ enum
> KERN_NMI_WATCHDOG=75, /* int: enable/disable nmi watchdog */
> KERN_PANIC_ON_NMI=76, /* int: whether we will panic on an unrecovered 
> */
> KERN_PANIC_ON_WARN=77, /* int: call panic() in WARN() functions */
> +   KERN_TIMEMAX=78,/* int: select maximum allowed system time */
>  };
>
>
> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> index ce410bb..6713a5b 100644
> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@ -1120,6 +1120,15 @@ static struct ctl_table kern_table[] = {
> .extra1 = ,
> .extra2 = ,
> },
> +   {
> +   .procname   = "time_max",
> +   .data   = _time_max,
> +   .maxlen = sizeof(int),
> +   .mode   = 0644,
> +   .proc_handler   = sysctl_time_max_handler,
> +   .extra1 = ,
> +   .extra2 = ,
> +   },
> { }
>  };
>
> diff --git a/kernel/sysctl_binary.c

Re: [RFC][PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

2015-04-15 Thread Arnd Bergmann 
On Wednesday 15 April 2015 17:41:28 Miroslav Lichvar wrote:
> On systems with 32-bit time_t, it seems there are quite a few problems
> that applications may have with time overflowing in year 2038. Beside
> getting in 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 be set close to the overflow
> accidentally or maliciously, e.g. when the clock 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 using 32-bit time_t are
> available.
> 
> Signed-off-by: Miroslav Lichvar 

I have just created a y2...@lists.linaro.org mailing list, added to Cc in
this reply.

The patch looks basically ok to me, though I have no opinion on whether
a sysctl is the best API for configuring this.

Arnd

> ---
>  Documentation/sysctl/kernel.txt | 19 +
>  include/linux/timekeeping.h |  5 
>  include/uapi/linux/sysctl.h |  1 +
>  kernel/sysctl.c |  9 ++
>  kernel/sysctl_binary.c  |  1 +
>  kernel/time/timekeeping.c   | 62 
> +
>  6 files changed, 91 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
> index 83ab256..08e4f28 100644
> --- a/Documentation/sysctl/kernel.txt
> +++ b/Documentation/sysctl/kernel.txt
> @@ -82,6 +82,7 @@ show up in /proc/sys/kernel:
>  - sysctl_writes_strict
>  - tainted
>  - threads-max
> +- time_max
>  - unknown_nmi_panic
>  - watchdog_thresh
>  - version
> @@ -847,6 +848,24 @@ can be ORed together:
>  
>  ==
>  
> +time_max:
> +
> +Select the maximum allowed value of the system time. The system clock cannot 
> be
> +set to a larger value and when it reaches the maximum on its own, it will be
> +stepped back by one week.
> +
> +0: No limit.
> +
> +1: One week before 32-bit time_t overflows, i.e. Jan 12 03:14:07 UTC 2038.
> +   This is currently the default value with 32-bit time_t, but it will likely
> +   change when 64-bit versions of system calls using time_t are available.
> +
> +2: One week before time in the internal kernel representation (ktime_t)
> +   overflows, i.e. Apr 4 23:47:16 UTC 2262. This is the default value with
> +   64-bit time_t.
> +
> +==
> +
>  unknown_nmi_panic:
>  
>  The value in this file affects behavior of handling NMI. When the
> diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
> index 99176af..51fc970 100644
> --- a/include/linux/timekeeping.h
> +++ b/include/linux/timekeeping.h
> @@ -5,6 +5,11 @@
>  
>  void timekeeping_init(void);
>  extern int timekeeping_suspended;
> +extern int sysctl_time_max;
> +
> +struct ctl_table;
> +extern int sysctl_time_max_handler(struct ctl_table *table, int write,
> + void __user *buffer, size_t *length, loff_t *ppos);
>  
>  /*
>   * Get and set timeofday
> diff --git a/include/uapi/linux/sysctl.h b/include/uapi/linux/sysctl.h
> index 0956373..8fd2aab 100644
> --- a/include/uapi/linux/sysctl.h
> +++ b/include/uapi/linux/sysctl.h
> @@ -154,6 +154,7 @@ enum
>   KERN_NMI_WATCHDOG=75, /* int: enable/disable nmi watchdog */
>   KERN_PANIC_ON_NMI=76, /* int: whether we will panic on an unrecovered */
>   KERN_PANIC_ON_WARN=77, /* int: call panic() in WARN() functions */
> + KERN_TIMEMAX=78,/* int: select maximum allowed system time */
>  };
>  
>  
> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> index ce410bb..6713a5b 100644
> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@ -1120,6 +1120,15 @@ static struct ctl_table kern_table[] = {
>   .extra1 = ,
>   .extra2 = ,
>   },
> + {
> + .procname   = "time_max",
> + .data   = _time_max,
> + .maxlen = sizeof(int),
> + .mode   = 0644,
> + .proc_handler   =

[RFC][PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

2015-04-15 Thread Miroslav Lichvar 
On systems with 32-bit time_t, it seems there are quite a few problems
that applications may have with time overflowing in year 2038. Beside
getting in 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 be set close to the overflow
accidentally or maliciously, e.g. when the clock 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 using 32-bit time_t are
available.

Signed-off-by: Miroslav Lichvar 
---
 Documentation/sysctl/kernel.txt | 19 +
 include/linux/timekeeping.h |  5 
 include/uapi/linux/sysctl.h |  1 +
 kernel/sysctl.c |  9 ++
 kernel/sysctl_binary.c  |  1 +
 kernel/time/timekeeping.c   | 62 +
 6 files changed, 91 insertions(+), 6 deletions(-)

diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index 83ab256..08e4f28 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -82,6 +82,7 @@ show up in /proc/sys/kernel:
 - sysctl_writes_strict
 - tainted
 - threads-max
+- time_max
 - unknown_nmi_panic
 - watchdog_thresh
 - version
@@ -847,6 +848,24 @@ can be ORed together:
 
 ==
 
+time_max:
+
+Select the maximum allowed value of the system time. The system clock cannot be
+set to a larger value and when it reaches the maximum on its own, it will be
+stepped back by one week.
+
+0: No limit.
+
+1: One week before 32-bit time_t overflows, i.e. Jan 12 03:14:07 UTC 2038.
+   This is currently the default value with 32-bit time_t, but it will likely
+   change when 64-bit versions of system calls using time_t are available.
+
+2: One week before time in the internal kernel representation (ktime_t)
+   overflows, i.e. Apr 4 23:47:16 UTC 2262. This is the default value with
+   64-bit time_t.
+
+==
+
 unknown_nmi_panic:
 
 The value in this file affects behavior of handling NMI. When the
diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
index 99176af..51fc970 100644
--- a/include/linux/timekeeping.h
+++ b/include/linux/timekeeping.h
@@ -5,6 +5,11 @@
 
 void timekeeping_init(void);
 extern int timekeeping_suspended;
+extern int sysctl_time_max;
+
+struct ctl_table;
+extern int sysctl_time_max_handler(struct ctl_table *table, int write,
+   void __user *buffer, size_t *length, loff_t *ppos);
 
 /*
  * Get and set timeofday
diff --git a/include/uapi/linux/sysctl.h b/include/uapi/linux/sysctl.h
index 0956373..8fd2aab 100644
--- a/include/uapi/linux/sysctl.h
+++ b/include/uapi/linux/sysctl.h
@@ -154,6 +154,7 @@ enum
KERN_NMI_WATCHDOG=75, /* int: enable/disable nmi watchdog */
KERN_PANIC_ON_NMI=76, /* int: whether we will panic on an unrecovered */
KERN_PANIC_ON_WARN=77, /* int: call panic() in WARN() functions */
+   KERN_TIMEMAX=78,/* int: select maximum allowed system time */
 };
 
 
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index ce410bb..6713a5b 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -1120,6 +1120,15 @@ static struct ctl_table kern_table[] = {
.extra1 = ,
.extra2 = ,
},
+   {
+   .procname   = "time_max",
+   .data   = _time_max,
+   .maxlen = sizeof(int),
+   .mode   = 0644,
+   .proc_handler   = sysctl_time_max_handler,
+   .extra1 = ,
+   .extra2 = ,
+   },
{ }
 };
 
diff --git a/kernel/sysctl_binary.c b/kernel/sysctl_binary.c
index 7e7746a..66c0946 100644
--- a/kernel/sysctl_binary.c
+++ b/kernel/sysctl_binary.c
@@ -138,6 +138,7 @@ static const struct bin_table bin_kern_table[] = {
{ CTL_INT,  KERN_MAX_LOCK_DEPTH,"max_lock_depth" },
{ CTL_INT,  KERN_PANIC_ON_NMI,

[RFC][PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

2015-04-15 Thread Miroslav Lichvar 
On systems with 32-bit time_t, it seems there are quite a few problems
that applications may have with time overflowing in year 2038. Beside
getting in 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 be set close to the overflow
accidentally or maliciously, e.g. when the clock 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 using 32-bit time_t are
available.

Signed-off-by: Miroslav Lichvar mlich...@redhat.com
---
 Documentation/sysctl/kernel.txt | 19 +
 include/linux/timekeeping.h |  5 
 include/uapi/linux/sysctl.h |  1 +
 kernel/sysctl.c |  9 ++
 kernel/sysctl_binary.c  |  1 +
 kernel/time/timekeeping.c   | 62 +
 6 files changed, 91 insertions(+), 6 deletions(-)

diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index 83ab256..08e4f28 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -82,6 +82,7 @@ show up in /proc/sys/kernel:
 - sysctl_writes_strict
 - tainted
 - threads-max
+- time_max
 - unknown_nmi_panic
 - watchdog_thresh
 - version
@@ -847,6 +848,24 @@ can be ORed together:
 
 ==
 
+time_max:
+
+Select the maximum allowed value of the system time. The system clock cannot be
+set to a larger value and when it reaches the maximum on its own, it will be
+stepped back by one week.
+
+0: No limit.
+
+1: One week before 32-bit time_t overflows, i.e. Jan 12 03:14:07 UTC 2038.
+   This is currently the default value with 32-bit time_t, but it will likely
+   change when 64-bit versions of system calls using time_t are available.
+
+2: One week before time in the internal kernel representation (ktime_t)
+   overflows, i.e. Apr 4 23:47:16 UTC 2262. This is the default value with
+   64-bit time_t.
+
+==
+
 unknown_nmi_panic:
 
 The value in this file affects behavior of handling NMI. When the
diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
index 99176af..51fc970 100644
--- a/include/linux/timekeeping.h
+++ b/include/linux/timekeeping.h
@@ -5,6 +5,11 @@
 
 void timekeeping_init(void);
 extern int timekeeping_suspended;
+extern int sysctl_time_max;
+
+struct ctl_table;
+extern int sysctl_time_max_handler(struct ctl_table *table, int write,
+   void __user *buffer, size_t *length, loff_t *ppos);
 
 /*
  * Get and set timeofday
diff --git a/include/uapi/linux/sysctl.h b/include/uapi/linux/sysctl.h
index 0956373..8fd2aab 100644
--- a/include/uapi/linux/sysctl.h
+++ b/include/uapi/linux/sysctl.h
@@ -154,6 +154,7 @@ enum
KERN_NMI_WATCHDOG=75, /* int: enable/disable nmi watchdog */
KERN_PANIC_ON_NMI=76, /* int: whether we will panic on an unrecovered */
KERN_PANIC_ON_WARN=77, /* int: call panic() in WARN() functions */
+   KERN_TIMEMAX=78,/* int: select maximum allowed system time */
 };
 
 
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index ce410bb..6713a5b 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -1120,6 +1120,15 @@ static struct ctl_table kern_table[] = {
.extra1 = zero,
.extra2 = one,
},
+   {
+   .procname   = time_max,
+   .data   = sysctl_time_max,
+   .maxlen = sizeof(int),
+   .mode   = 0644,
+   .proc_handler   = sysctl_time_max_handler,
+   .extra1 = zero,
+   .extra2 = two,
+   },
{ }
 };
 
diff --git a/kernel/sysctl_binary.c b/kernel/sysctl_binary.c
index 7e7746a..66c0946 100644
--- a/kernel/sysctl_binary.c
+++ b/kernel/sysctl_binary.c
@@ -138,6 +138,7 @@ static const struct bin_table bin_kern_table[] = {
{ CTL_INT,  KERN_MAX_LOCK_DEPTH,max_lock_depth },
{ CTL_INT,  KERN_PANIC_ON_NMI,

Re: [RFC][PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

2015-04-15 Thread Arnd Bergmann 
On Wednesday 15 April 2015 17:41:28 Miroslav Lichvar wrote:
 On systems with 32-bit time_t, it seems there are quite a few problems
 that applications may have with time overflowing in year 2038. Beside
 getting in 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 be set close to the overflow
 accidentally or maliciously, e.g. when the clock 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 using 32-bit time_t are
 available.
 
 Signed-off-by: Miroslav Lichvar mlich...@redhat.com

I have just created a y2...@lists.linaro.org mailing list, added to Cc in
this reply.

The patch looks basically ok to me, though I have no opinion on whether
a sysctl is the best API for configuring this.

Arnd

 ---
  Documentation/sysctl/kernel.txt | 19 +
  include/linux/timekeeping.h |  5 
  include/uapi/linux/sysctl.h |  1 +
  kernel/sysctl.c |  9 ++
  kernel/sysctl_binary.c  |  1 +
  kernel/time/timekeeping.c   | 62 
 +
  6 files changed, 91 insertions(+), 6 deletions(-)
 
 diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
 index 83ab256..08e4f28 100644
 --- a/Documentation/sysctl/kernel.txt
 +++ b/Documentation/sysctl/kernel.txt
 @@ -82,6 +82,7 @@ show up in /proc/sys/kernel:
  - sysctl_writes_strict
  - tainted
  - threads-max
 +- time_max
  - unknown_nmi_panic
  - watchdog_thresh
  - version
 @@ -847,6 +848,24 @@ can be ORed together:
  
  ==
  
 +time_max:
 +
 +Select the maximum allowed value of the system time. The system clock cannot 
 be
 +set to a larger value and when it reaches the maximum on its own, it will be
 +stepped back by one week.
 +
 +0: No limit.
 +
 +1: One week before 32-bit time_t overflows, i.e. Jan 12 03:14:07 UTC 2038.
 +   This is currently the default value with 32-bit time_t, but it will likely
 +   change when 64-bit versions of system calls using time_t are available.
 +
 +2: One week before time in the internal kernel representation (ktime_t)
 +   overflows, i.e. Apr 4 23:47:16 UTC 2262. This is the default value with
 +   64-bit time_t.
 +
 +==
 +
  unknown_nmi_panic:
  
  The value in this file affects behavior of handling NMI. When the
 diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
 index 99176af..51fc970 100644
 --- a/include/linux/timekeeping.h
 +++ b/include/linux/timekeeping.h
 @@ -5,6 +5,11 @@
  
  void timekeeping_init(void);
  extern int timekeeping_suspended;
 +extern int sysctl_time_max;
 +
 +struct ctl_table;
 +extern int sysctl_time_max_handler(struct ctl_table *table, int write,
 + void __user *buffer, size_t *length, loff_t *ppos);
  
  /*
   * Get and set timeofday
 diff --git a/include/uapi/linux/sysctl.h b/include/uapi/linux/sysctl.h
 index 0956373..8fd2aab 100644
 --- a/include/uapi/linux/sysctl.h
 +++ b/include/uapi/linux/sysctl.h
 @@ -154,6 +154,7 @@ enum
   KERN_NMI_WATCHDOG=75, /* int: enable/disable nmi watchdog */
   KERN_PANIC_ON_NMI=76, /* int: whether we will panic on an unrecovered */
   KERN_PANIC_ON_WARN=77, /* int: call panic() in WARN() functions */
 + KERN_TIMEMAX=78,/* int: select maximum allowed system time */
  };
  
  
 diff --git a/kernel/sysctl.c b/kernel/sysctl.c
 index ce410bb..6713a5b 100644
 --- a/kernel/sysctl.c
 +++ b/kernel/sysctl.c
 @@ -1120,6 +1120,15 @@ static struct ctl_table kern_table[] = {
   .extra1 = zero,
   .extra2 = one,
   },
 + {
 + .procname   = time_max,
 + .data   = sysctl_time_max,
 + .maxlen = sizeof(int),
 + .mode   = 0644,
 + .proc_handler   = sysctl_time_max_handler,
 + .extra1 = zero,
 + .extra2 = two,

Re: [RFC][PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

2015-04-15 Thread Justin Keller 
Is there a reason for step = leap?
On Wed, Apr 15, 2015 at 11:41 AM, Miroslav Lichvar mlich...@redhat.com wrote:
 On systems with 32-bit time_t, it seems there are quite a few problems
 that applications may have with time overflowing in year 2038. Beside
 getting in 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 be set close to the overflow
 accidentally or maliciously, e.g. when the clock 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 using 32-bit time_t are
 available.

 Signed-off-by: Miroslav Lichvar mlich...@redhat.com
 ---
  Documentation/sysctl/kernel.txt | 19 +
  include/linux/timekeeping.h |  5 
  include/uapi/linux/sysctl.h |  1 +
  kernel/sysctl.c |  9 ++
  kernel/sysctl_binary.c  |  1 +
  kernel/time/timekeeping.c   | 62 
 +
  6 files changed, 91 insertions(+), 6 deletions(-)

 diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
 index 83ab256..08e4f28 100644
 --- a/Documentation/sysctl/kernel.txt
 +++ b/Documentation/sysctl/kernel.txt
 @@ -82,6 +82,7 @@ show up in /proc/sys/kernel:
  - sysctl_writes_strict
  - tainted
  - threads-max
 +- time_max
  - unknown_nmi_panic
  - watchdog_thresh
  - version
 @@ -847,6 +848,24 @@ can be ORed together:

  ==

 +time_max:
 +
 +Select the maximum allowed value of the system time. The system clock cannot 
 be
 +set to a larger value and when it reaches the maximum on its own, it will be
 +stepped back by one week.
 +
 +0: No limit.
 +
 +1: One week before 32-bit time_t overflows, i.e. Jan 12 03:14:07 UTC 2038.
 +   This is currently the default value with 32-bit time_t, but it will likely
 +   change when 64-bit versions of system calls using time_t are available.
 +
 +2: One week before time in the internal kernel representation (ktime_t)
 +   overflows, i.e. Apr 4 23:47:16 UTC 2262. This is the default value with
 +   64-bit time_t.
 +
 +==
 +
  unknown_nmi_panic:

  The value in this file affects behavior of handling NMI. When the
 diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
 index 99176af..51fc970 100644
 --- a/include/linux/timekeeping.h
 +++ b/include/linux/timekeeping.h
 @@ -5,6 +5,11 @@

  void timekeeping_init(void);
  extern int timekeeping_suspended;
 +extern int sysctl_time_max;
 +
 +struct ctl_table;
 +extern int sysctl_time_max_handler(struct ctl_table *table, int write,
 +   void __user *buffer, size_t *length, loff_t *ppos);

  /*
   * Get and set timeofday
 diff --git a/include/uapi/linux/sysctl.h b/include/uapi/linux/sysctl.h
 index 0956373..8fd2aab 100644
 --- a/include/uapi/linux/sysctl.h
 +++ b/include/uapi/linux/sysctl.h
 @@ -154,6 +154,7 @@ enum
 KERN_NMI_WATCHDOG=75, /* int: enable/disable nmi watchdog */
 KERN_PANIC_ON_NMI=76, /* int: whether we will panic on an unrecovered 
 */
 KERN_PANIC_ON_WARN=77, /* int: call panic() in WARN() functions */
 +   KERN_TIMEMAX=78,/* int: select maximum allowed system time */
  };


 diff --git a/kernel/sysctl.c b/kernel/sysctl.c
 index ce410bb..6713a5b 100644
 --- a/kernel/sysctl.c
 +++ b/kernel/sysctl.c
 @@ -1120,6 +1120,15 @@ static struct ctl_table kern_table[] = {
 .extra1 = zero,
 .extra2 = one,
 },
 +   {
 +   .procname   = time_max,
 +   .data   = sysctl_time_max,
 +   .maxlen = sizeof(int),
 +   .mode   = 0644,
 +   .proc_handler   = sysctl_time_max_handler,
 +   .extra1 = zero,
 +   .extra2 = two,
 +   },
 { }
  };

 diff --git a/kernel/sysctl_binary.c b/kernel/sysctl_binary.c
 index 7e7746a..66c0946 100644
 --- a/kernel/sysctl_binary.c

Re: [RFC][PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

2015-04-15 Thread One Thousand Gnomes 
On Wed, 15 Apr 2015 17:41:28 +0200
Miroslav Lichvar mlich...@redhat.com wrote:

 On systems with 32-bit time_t, it seems there are quite a few problems
 that applications may have with time overflowing in year 2038. Beside

Even ext4 is still broken for 2038.

 larger value. When the maximum is reached in normal time accumulation,
 the clock will be stepped back by one week.

Which itself is open to exploits and dirty tricks and causes bizarre
problems. IMHO it doesn't actually improve the situation.

Alan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/