linux-stable.git/kernel/time/ntp.c, branch v4.9.321

ntp: Limit TAI-UTC offset

2019-08-04T07:33:21+00:00

[ Upstream commit d897a4ab11dc8a9fda50d2eccc081a96a6385998 ]

Don't allow the TAI-UTC offset of the system clock to be set by adjtimex()
to a value larger than 100000 seconds.

This prevents an overflow in the conversion to int, prevents the CLOCK_TAI
clock from getting too far ahead of the CLOCK_REALTIME clock, and it is
still large enough to allow leap seconds to be inserted at the maximum rate
currently supported by the kernel (once per day) for the next ~270 years,
however unlikely it is that someone can survive a catastrophic event which
slowed down the rotation of the Earth so much.

Reported-by: Weikang shi 
Signed-off-by: Miroslav Lichvar 
Signed-off-by: Thomas Gleixner 
Cc: John Stultz 
Cc: Prarit Bhargava 
Cc: Richard Cochran 
Cc: Stephen Boyd 
Link: https://lkml.kernel.org/r/20190618154713.20929-1-mlichvar@redhat.com
Signed-off-by: Sasha Levin

ntp: Allow TAI-UTC offset to be set to zero

2019-06-22T06:17:14+00:00

[ Upstream commit fdc6bae940ee9eb869e493990540098b8c0fd6ab ]

The ADJ_TAI adjtimex mode sets the TAI-UTC offset of the system clock.
It is typically set by NTP/PTP implementations and it is automatically
updated by the kernel on leap seconds. The initial value is zero (which
applications may interpret as unknown), but this value cannot be set by
adjtimex. This limitation seems to go back to the original "nanokernel"
implementation by David Mills.

Change the ADJ_TAI check to accept zero as a valid TAI-UTC offset in
order to allow setting it back to the initial value.

Fixes: 153b5d054ac2 ("ntp: support for TAI")
Suggested-by: Ondrej Mosnacek 
Signed-off-by: Miroslav Lichvar 
Signed-off-by: Thomas Gleixner 
Cc: John Stultz 
Cc: Richard Cochran 
Cc: Prarit Bhargava 
Link: https://lkml.kernel.org/r/20190417084833.7401-1-mlichvar@redhat.com
Signed-off-by: Sasha Levin

ntp: Fix ADJ_SETOFFSET being used w/ ADJ_NANO

2016-01-22T11:01:42+00:00

Recently, in commit 37cf4dc3370f I forgot to check if the timeval being passed
was actually a timespec (as is signaled with ADJ_NANO).

This resulted in that patch breaking ADJ_SETOFFSET users who set
ADJ_NANO, by rejecting valid timespecs that were compared with
valid timeval ranges.

This patch addresses this by checking for the ADJ_NANO flag and
using the timepsec check instead in that case.

Reported-by: Harald Hoyer 
Reported-by: Kay Sievers 
Fixes: 37cf4dc3370f "time: Verify time values in adjtimex ADJ_SETOFFSET to avoid overflow"
Signed-off-by: John Stultz 
Cc: Sasha Levin 
Cc: Richard Cochran 
Cc: Prarit Bhargava 
Cc: David Herrmann 
Link: http://lkml.kernel.org/r/1453417415-19110-2-git-send-email-john.stultz@linaro.org
Signed-off-by: Thomas Gleixner

ntp: Fix second_overflow's input parameter type to be 64bits

2015-12-17T00:50:56+00:00

The function "second_overflow" uses "unsign long"
as its input parameter type which will overflow after
year 2106 on 32bit systems.

Thus this patch replaces it with time64_t type.

While the 64-bit division is expensive, "next_ntp_leap_sec"
has been calculated already, so we can just re-use it in the
TIME_INS/DEL cases, allowing one expensive division per
leapsecond instead of re-doing the divsion once a second after
the leap flag has been set.

Signed-off-by: DengChao 
[jstultz: Tweaked commit message]
Signed-off-by: John Stultz

ntp: Change time_reftime to time64_t and utilize 64bit __ktime_get_real_seconds

2015-12-17T00:50:55+00:00

The type of static variant "time_reftime" and the call of
get_seconds in ntp are both not y2038 safe.

So change the type of time_reftime to time64_t and replace
get_seconds with __ktime_get_real_seconds.

The local variant "secs" in ntp_update_offset represents
seconds between now and last ntp adjustment, it seems impossible
that this time will last more than 68 years, so keep its type as
"long".

Reviewed-by: John Stultz 
Signed-off-by: DengChao 
[jstultz: Tweaked commit message]
Signed-off-by: John Stultz

time: Verify time values in adjtimex ADJ_SETOFFSET to avoid overflow

2015-12-11T06:41:06+00:00

For adjtimex()'s ADJ_SETOFFSET, make sure the tv_usec value is
sane. We might multiply them later which can cause an overflow
and undefined behavior.

This patch introduces new helper functions to simplify the
checking code and adds comments to clarify

Orginally this patch was by Sasha Levin, but I've basically
rewritten it, so he should get credit for finding the issue
and I should get the blame for any mistakes made since.

Also, credit to Richard Cochran for the phrasing used in the
comment for what is considered valid here.

Cc: Sasha Levin 
Cc: Richard Cochran 
Cc: Thomas Gleixner 
Reported-by: Sasha Levin 
Signed-off-by: John Stultz

ntp: Verify offset doesn't overflow in ntp_update_offset

2015-12-11T06:41:05+00:00

We need to make sure that the offset is valid before manipulating it,
otherwise it might overflow on the multiplication.

Cc: Sasha Levin 
Cc: Richard Cochran 
Cc: Thomas Gleixner 
Signed-off-by: Sasha Levin 
[jstultz: Reworked one of the checks so it makes more sense]
Signed-off-by: John Stultz

ntp: use timespec64 in sync_cmos_clock

2015-10-01T16:59:07+00:00

The sync_cmos_clock has one use of struct timespec, which we want to
eventually replace with timespec64 or similar in the kernel. There
is no way this one can overflow, but the conversion to timespec64
is trivial and has no other dependencies.

Acked-by: Richard Cochran 
Acked-by: David S. Miller 
Reviewed-by: Thomas Gleixner 
Signed-off-by: Arnd Bergmann 
Signed-off-by: John Stultz

ntp/pps: use timespec64 for hardpps()

2015-10-01T16:57:59+00:00

There is only one user of the hardpps function in the kernel, so
it makes sense to atomically change it over to using 64-bit
timestamps for y2038 safety. In the hardpps implementation,
we also need to change the pps_normtime structure, which is
similar to struct timespec and also requires a 64-bit
seconds portion.

This introduces two temporary variables in pps_kc_event() to
do the conversion, they will be removed again in the next step,
which seemed preferable to having a larger patch changing it
all at the same time.

Acked-by: Richard Cochran 
Acked-by: David S. Miller 
Reviewed-by: Thomas Gleixner 
Signed-off-by: Arnd Bergmann 
Signed-off-by: John Stultz

time: Add the common weak version of update_persistent_clock()

2015-08-17T18:25:16+00:00

The weak update_persistent_clock64() calls update_persistent_clock(),
if the architecture defines an update_persistent_clock64() to replace
and remove its update_persistent_clock() version, when building the
kernel the linker will throw an undefined symbol error, that is, any
arch that switches to update_persistent_clock64() will have this issue.

To solve the issue, we add the common weak update_persistent_clock().

Cc: Prarit Bhargava 
Cc: Richard Cochran 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: Arnd Bergmann 
Signed-off-by: Xunlei Pang 
Signed-off-by: John Stultz