linux-kernel - Re: [v3] x86/tsc: Unset TSC_KNOWN_FREQ and TSC

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]

Message-ID: <3d35fda5-418b-f022-1191-c53bd9468f4d@intel.com>
Date:   Thu, 13 Feb 2020 10:32:11 -0800
From:   Dave Hansen <dave.hansen@...el.com>
To:     Thomas Gleixner <tglx@...utronix.de>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:     Hans de Goede <hdegoede@...hat.com>,
        vipul kumar <vipulk0511@...il.com>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        linux-kernel@...r.kernel.org, Stable <stable@...r.kernel.org>,
        Srikanth Krishnakar <Srikanth_Krishnakar@...tor.com>,
        Cedric Hombourger <Cedric_Hombourger@...tor.com>,
        x86@...nel.org, Len Brown <len.brown@...el.com>,
        Vipul Kumar <vipul_kumar@...tor.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [v3] x86/tsc: Unset TSC_KNOWN_FREQ and TSC_RELIABLE flags on
 Intel Bay Trail SoC

On 1/29/20 12:57 PM, Thomas Gleixner wrote:
> Just to make it entirely clear. We are wasting days already due to the
> fact that Intel, who designs, specifies and most importantly sells these
> CPUs is either unable or unwilling to provide accurate information about
> the trivial and essential information to support these CPUs:
> 
>     1) The crystal frequency
> 
>     2) The nominator/denominator pair to calculate the TSC frequency
>        from #1

Circling back...  The problem here, as I understand it is that we have
some of these tables:

static const struct freq_desc freq_desc_byt = {
        1, { 83300, 100000, 133300, 116700, 80000, 0, 0, 0 }
};

Where "83300" means "83.3 MHz".  the 83.3 came literally from the SDM.
Talking to some of the folks who work on the silicon, they confirmed
that when the SDM says "083.3 MHz", it represents an approximation of
2000/24.
Intel can go through and explain the values more precisely in the
documentation.  The big-core tables already have more significant
digits, for instance.  To me, it also seems like the SDM should probably
just explicitly state the actual ratios rather than a decimal approximation.

But, in the end, the CPU is just enumerating frequencies that are
derived from crystals outside the CPU.  The hardware in question here
tended to be put on boards which were not using the highest-end
components and probably don't have the most accurate crystals.

So, while we can add precision to the numbers in the documentation,
we're not super confident that it will result in a meaningfully more
accurate frequency across a big fleet of systems.