linux-kernel - Re: [PATCH] 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>] [day] [month] [year] [list]

Message-ID: <871rrye86i.fsf@nanos.tec.linutronix.de>
Date:   Fri, 17 Jan 2020 10:36:21 +0100
From:   Thomas Gleixner <tglx@...utronix.de>
To:     vipul kumar <vipulk0511@...il.com>
Cc:     linux-kernel@...r.kernel.org,
        Srikanth Krishnakar <Srikanth_Krishnakar@...tor.com>,
        Cedric Hombourger <Cedric_Hombourger@...tor.com>,
        Vipul Kumar <vipul_kumar@...tor.com>, x86@...nel.org,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Len Brown <len.brown@...el.com>
Subject: Re: [PATCH] x86/tsc: Unset TSC_KNOWN_FREQ and TSC_RELIABLE flags on Intel Bay Trail SoC

Vipul,

vipul kumar <vipulk0511@...il.com> writes:
> On Fri, Jan 17, 2020 at 3:34 AM Thomas Gleixner <tglx@...utronix.de> wrote:
>> Vipul Kumar <vipulk0511@...il.com> writes:
>> Can you please provide detailed data about the problem you are trying to
>> solve? 'time drift' is pretty unspecific.
>
> After running board for some days without rebooting it, time drift is
> observed between system time and RTC time.
>
> SystemTime: 2019-11-08T15:48:46+00:00 RTC Time:   2019-11-08
> 15:44:35.976137+0000 Uptime: up 7 days 5 hours, 33 minutes
>
> This sample shows a difference of 4 minutes after 7 days.

Of course you fail to provide the data for the case where the frequency
is recalibrated, i.e. with your patch applied.

> To fix this drift issue, disable X86_FEATURE_TSC_KNOWN_FREQ flag for Soc's
> having  cpuid_level < 0x15.

Again, I explained you already that this does not work on SoCs which do
not expose HPET or PIT.

And again, it has absolutely nothing to do with the CPUID level because
these chips are not using CPUID to retrieve the frequency
information. They use cpu_khz_from_msr() which only depends on the CPU
model/family.

So if you want to enforce refined calibration on such systems, then you
need to do it in a way which does not break the world.

Thanks,

        tglx