linux-kernel - Re: [PATCH] x86/tsc: mark tsc reliable for qualified platforms

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

Message-ID: <20210308014234.GA84425@shbuild999.sh.intel.com>
Date:   Mon, 8 Mar 2021 09:42:34 +0800
From:   Feng Tang <feng.tang@...el.com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Ingo Molnar <mingo@...hat.com>, H Peter Anvin <hpa@...or.com>,
        Borislav Petkov <bp@...en8.de>,
        Peter Zijlstra <peterz@...radead.org>,
        "x86@...nel.org" <x86@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Zhang, Rui" <rui.zhang@...el.com>,
        "Hansen, Dave" <dave.hansen@...el.com>,
        "Kleen, Andi" <andi.kleen@...el.com>,
        "Brown, Len" <len.brown@...el.com>
Subject: Re: [PATCH] x86/tsc: mark tsc reliable for qualified platforms

On Wed, Mar 03, 2021 at 10:51:31PM +0800, Thomas Gleixner wrote:
> On Tue, Mar 02 2021 at 10:52, Feng Tang wrote:
> > There are cases that tsc clocksource are wrongly judged as unstable by
> > clocksource watchdogs like hpet, acpi_pm or 'refined-jiffies'. While
> > there is hardly a general reliable way to check the validity of a
> > watchdog, and to protect the innocent tsc, Thomas Gleixner proposed [1]:
> >
> > "I'm inclined to lift that requirement when the CPU has:
> >
> >     1) X86_FEATURE_CONSTANT_TSC
> >     2) X86_FEATURE_NONSTOP_TSC
> >     3) X86_FEATURE_NONSTOP_TSC_S3
> >     4) X86_FEATURE_TSC_ADJUST
> >     5) At max. 4 sockets
> >
> >  After two decades of horrors we're finally at a point where TSC seems
> >  to be halfway reliable and less abused by BIOS tinkerers. TSC_ADJUST
> >  was really key as we can now detect even small modifications reliably
> >  and the important point is that we can cure them as well (not pretty
> >  but better than all other options)."
> >
> > So implement it with slight change as discussed in the thread, and be
> > more defensive to use maxim of 2 sockets.
> 
> Can you please explain the slight change in the changelog?
 
Sorry for the late response. Just found this mail in my "Junk Mail"
folder with 3 copies, interesting mail sever filters!

I will add 
"As feature #3 X86_FEATURE_NONSTOP_TSC_S3 only exists on several
generations of Atom processor, and is always coupled with 
X86_FEATURE_CONSTANT_TSC and X86_FEATURE_NONSTOP_TSC, skip checking
it"
to the commit log.

Thanks,
Feng



> Thanks,
> 
>         tglx