linux-kernel - Re: [PATCH] x86/tsc: Add option to force HW timer based recalibration

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:   Mon, 09 May 2022 12:01:42 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Feng Tang <feng.tang@...el.com>,
        Peter Zijlstra <peterz@...radead.org>
Cc:     Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...el.com>,
        "H . Peter Anvin" <hpa@...or.com>,
        Jonathan Corbet <corbet@....net>, x86@...nel.org,
        linux-kernel@...r.kernel.org, paulmck@...nel.org,
        rui.zhang@...el.com, len.brown@...el.com, tim.c.chen@...el.com
Subject: Re: [PATCH] x86/tsc: Add option to force HW timer based recalibration

Feng,

On Mon, May 09 2022 at 15:30, Feng Tang wrote:
> On Mon, May 09, 2022 at 09:16:52AM +0200, Peter Zijlstra wrote:
>> On Mon, May 09, 2022 at 12:58:39PM +0800, Feng Tang wrote:
>> > And there is still very few corner case that the freq info is not
>> > accurate enough with small deviation from the actual value, like on
>> > a product with early buggy version of firmware or on some
>> > pre-production hardware.
>> >
>> > Add an option 'recalibrate' for 'tsc' kernel parameter to force the
>> > tsc freq recalibration with HPET/PM_TIMER, and warn if the deviation
>> > from previous value is more than about 500 PPM.
>> > 
>> > Signed-off-by: Feng Tang <feng.tang@...el.com>
>> 
>> Why isn't 'tsc_early_khz=' not working for you? Afaict that will
>> override calibrate_tsc() when provided and as such can be used on these
>> early platforms for provide the right value until such time that the
>> firmware is fixed.
>
> For the early platforms, the problem we met is we don't know what
> is the 'correct' tsc-freq, and the value from MSR/CUPID could be wrong. 
>
> And there was some generation, that after enabling some feature, each
> instance of HW will have slightly different frequency, so there is
> no central "one for all" value to set for 'tsc_early_khz'.
>
> This option is more like a way to double-check the correctness of
> tsc-freq got from MSR/CPUID(0x15).

If at all it's a workaround for the inability and ignorance of firmware
people. The crystal frequency and the TSC/crystal ratio _are_ known to
the system designer and firmware people. It's really not asked too much
to put the correct values into CPUID(0x15) and have proper quality
control to ensure the correctness.

The whole argument about early firmware and pre-production hardware is
bogus. It's 2022 and we are debating this problem for more than a decade
now and still hardware and firmware people think they can do what they
want and it all can be "fixed" in software. It's not rocket science to
get this straight.

Aside of that HPET has become unrealiable and PM timer is not guaranteed
to be there either. So we really do not need a mechanism to enforce
recalibration against something which is not guaranteed to provide
sensible information.

Thanks,

        tglx