linux-kernel - Unable to move system time back on recent Core i7 systems

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-next>] [day] [month] [year] [list]

Message-ID: <69446042-faa6-2360-1a24-0ce48c78dd25@dolezel.info>
Date:   Tue, 29 Aug 2017 21:10:39 +0200
From:   Luboš Doležel <lubos@...ezel.info>
To:     linux-kernel@...r.kernel.org
Subject: Unable to move system time back on recent Core i7 systems

Hello,

I'm hitting a strange bug on some of my Linux systems with various 4.x 
kernels.

I cannot set the system time to anything before the current system time.

This includes ntpd not being able to keep the clock in sync if the 
system clock is a little too fast. So it's not limited to just setting 
the time back to the 90s, but it actually breaks time synchronization on 
my server system.

Essentially, settimeofday() and clock_settime() system calls succeed, 
but any subsequent gettimeofday() etc. call will return unaltered time.

E.g.:

$ sudo date -s 1998-08-01
Sat Aug  1 00:00:00 CEST 1998
$ date
Tue Aug 29 20:59:25 CEST 2017

I have been able to reproduce the problem on these CPUs:

* Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz
* Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz

I *cannot* reproduce the problem on these CPUs, even if I boot the same 
kernel version as on the CPUs above:

* Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
* Intel(R) Core(TM) i5-3570K CPU @ 3.40GHz
* Various even older CPUs

I tried to google the problem, but turned up with nothing. This brings 
several questions:

1) What the hell?
2) Am I the only one having this problem?
3) Can the Linux kernel developers possibly do something about this, if 
this problem is confirmed?

Thanks,
Lubos