linux-kernel - Re: [PATCH RFC] x86/tsc: Make recalibration default on for TSC_KNOWN

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

Message-ID: <ZGtnUQJy+1Nrazhy@feng-clx>
Date:   Mon, 22 May 2023 21:00:01 +0800
From:   Feng Tang <feng.tang@...el.com>
To:     Thomas Gleixner <tglx@...utronix.de>
CC:     Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "Dave Hansen" <dave.hansen@...el.com>,
        "H . Peter Anvin" <hpa@...or.com>,
        "Peter Zijlstra" <peterz@...radead.org>, <paulmck@...nel.org>,
        <rui.zhang@...el.com>, <x86@...nel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RFC] x86/tsc: Make recalibration default on for
 TSC_KNOWN_FREQ cases

On Mon, May 22, 2023 at 01:49:53PM +0200, Thomas Gleixner wrote:
> On Mon, May 22 2023 at 16:47, Feng Tang wrote:
> > On Mon, May 22, 2023 at 10:14:08AM +0200, Thomas Gleixner wrote:
> >> On Mon, May 22 2023 at 11:30, Feng Tang wrote:
> >> Are any of these affected platforms shipping already or is this just
> >> Intel internal muck?
> >
> > Paul and Rui can provide more info. AFAIK, those problems were raised
> > by external customers, so the platform were already shipped from
> > Intel. But I'm not sure they are commercial versions or early
> > engineering drops. 
> 
> So its at a company which knows how to update firmware, right?

Yes. And the recalibration may help to exposed the bug quickly.

> >> So why do you force this on everyone?
> >
> > How about we keep the optional parameter, and enforce the check for
> > bare metal platforms which got TSC frequency info from CPUID(0x15),
> > like:
> 
> What prevents a hypervisor from providing this info in CPUID(0x15)?
> 
> > @@ -670,8 +670,10 @@ unsigned long native_calibrate_tsc(void)
> >  	 * frequency and is the most accurate one so far we have. This
> >  	 * is considered a known frequency.
> >  	 */
> > -	if (crystal_khz != 0)
> > +	if (crystal_khz != 0) {
> >  		setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ);
> > +		tsc_force_recalibrate = 1;
> > +	}
> >  
> >  	/*
> >  	 * Some Intel SoCs like Skylake and Kabylake don't report the crystal
> 
> and five lines further down:
> 
> 	/*
> 	 * For Atom SoCs TSC is the only reliable clocksource.
> 	 * Mark TSC reliable so no watchdog on it.
> 	 */
> 	if (boot_cpu_data.x86_model == INTEL_FAM6_ATOM_GOLDMONT)
> 		setup_force_cpu_cap(X86_FEATURE_TSC_RELIABLE);
> 
> So its reliable and needs recalibration against hardware which does not
> exist.

I misunderstood it. When you said 'SOCs which lack legacy hardware',
I thought you were referring those old Merrifield/Medfield things,
which may have no HPET/ACPI PM_Timer but an APB timer, and mainly go
through MSR way (tsc_msr.c) for TSC frequency.

In this native_calibrate_tsc(), which touches the INTEL_FAM6_ATOM_GOLDMONT
and INTEL_FAM6_ATOM_GOLDMONT_D, I dug out one Apollo Lake and one
Denverton platform (which comply to those GOLDMNOT model), and they
both have 'hpet' and 'acpi_pm' clocksource registered. 

Thanks,
Feng

> 
> Thanks,
> 
>        tglx