linux-kernel - Re: Re: [PATCH 2/2] x86: use KNOWN_FREQ and RELIABLE TSC flags on certain processors/SoCs

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]

Date:   Thu, 10 Nov 2016 16:06:34 -0800
From:   Bin Gao <bin.gao@...ux.intel.com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Ingo Molnar <mingo@...hat.com>, H Peter Anvin <hpa@...or.com>,
        x86@...nel.org, Peter Zijlstra <peterz@...radead.org>,
        linux-kernel@...r.kernel.org, Bin Gao <bin.gao@...el.com>
Subject: Re: Re: [PATCH 2/2] x86: use KNOWN_FREQ and RELIABLE TSC flags on
 certain processors/SoCs

On Fri, Nov 11, 2016 at 12:26:40AM +0100, Thomas Gleixner wrote:
> On Thu, 10 Nov 2016, Bin Gao wrote:
> > > > @@ -702,6 +702,15 @@ unsigned long native_calibrate_tsc(void)
> > > >  		}
> > > >  	}
> > > >  
> > > > +	setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ);
> > > 
> > > I can understand the one below, but this one changes existing behaviour w/o explaining why this is correct and desired. If at all then this wants to be a seperate patch and not just mingled in your goldmont update.
> > 
> > native_calibrate_tsc() implements determining TSC frequency via CPUID.
> > The purpose to add X86_FEATURE_TSC_KNOWN_FREQ flag is exactly for this case:
> > TSC frequency determined via CPUID or MSR are always correct and the whole
> > calibration should be skipped.
> 
> Did you actually verify that this is correct and does not introduce NTP
> issues compared to the long term calibration on such platforms?
> 
> We've been burnt before and myself and others wasted enough time already
> debugging that crap.

Yes, we had a 24 hours test before on one of the CPUID capable platforms.
With PIT calibrated frequency, we got more than 3 seconds drift whereas
with CPUID determined frequency we only got less than 0.5 second drift.

Another fact is that on MSR capable platforms, PIT/HPET is generally not
available so calibration won't work at all.