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 for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAG3POBnGPabdLQ2wvJc9HTKeHszf+RytV6t+hPyh0k=hjGd+8g@mail.gmail.com>
Date:   Sun, 23 Dec 2018 14:56:01 +0800
From:   Da Shi Cao <dscao999@...il.com>
To:     linux-kernel@...r.kernel.org, linux-x86_64@...r.kernel.org
Subject: [BUG]Uncalibrated TSC is not accurate enough as a time keeper

The cpu_khz and tsc_khz are now read directly by the cpuid
instruction, and they are deemed to be very accurate. But this is not
the case in our situation. The OS time lags behind about 8 seconds per
hour. The CPU information is as follows:
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 85
model name      : Intel(R) Xeon(R) Gold 6140 CPU @ 2.30GHz
stepping        : 4
microcode       : 0x200004d
cpu MHz         : 2300.000
cache size      : 25344 KB
physical id     : 0
siblings        : 36
core id         : 0
cpu cores       : 18
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 22
It is this "cpuid level 22" that makes the kernel 4.14 to read both
cpu_khz and tsc_khz directly by instruction "cpuid", and the TSC is
thought to be very accurate, but in fact it is not.
------------
* TSC frequency determined by CPUID is a "hardware reported"
* frequency and is the most accurate one so far we have. This
* is considered a known frequency.
+*
+*  The assumption may not be valid!
+*
*/
-  setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ);

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ