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: <87pm6swi7z.ffs@tglx>
Date:   Mon, 22 May 2023 16:31:28 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Feng Tang <feng.tang@...el.com>
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 21:00, Feng Tang wrote:
> On Mon, May 22, 2023 at 01:49:53PM +0200, Thomas Gleixner wrote:
>> > 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.

That should be exposed _before_ crappy firmware is shipped and
validation can use the command line parameter. I'm tired of this
constant source of embarrassing stupidity. It's not rocket science to
catch this before shipping.

And guess what. Making this easy to recover from is just not making the
situation any better because firmware people will even care less.

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

So that comment is wrong and that commit log is from fantasy land?

  http://lkml.kernel.org/r/1479241644-234277-4-git-send-email-bin.gao@linux.intel.com

Clearly the left hand is not knowing what the right hand is doing.

Thanks,

        tglx