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-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <86dd629b-c744-e881-0613-ab7d9e189083@infradead.org>
Date:   Tue, 29 Aug 2017 15:18:16 -0700
From:   Randy Dunlap <rdunlap@...radead.org>
To:     Luboš Doležel <lubos@...ezel.info>,
        linux-kernel@...r.kernel.org
Subject: Re: Unable to move system time back on recent Core i7 systems

On 08/29/17 12:10, Luboš Doležel wrote:
> 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

Is ntp daemon running?

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


-- 
~Randy

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ