linux-kernel - [PATCH 0/2] Fix TSC issues on (some) AMD Ryzen based systems

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

Message-Id: <20190129102329.27610-1-jan@schnhrr.de>
Date:   Tue, 29 Jan 2019 11:23:27 +0100
From:   Jan H. Schönherr <jan@...nhrr.de>
To:     Borislav Petkov <bp@...en8.de>, Ingo Molnar <mingo@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>, x86@...nel.org
Cc:     Jan H. Schönherr <jan@...nhrr.de>,
        Paul Menzel <pmenzel@...gen.mpg.de>,
        Thomas Lendacky <Thomas.Lendacky@....com>,
        "H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org
Subject: [PATCH 0/2] Fix TSC issues on (some) AMD Ryzen based systems

My newly acquired AMD Ryzen Threadripper based system seems to have
some TSC quirks, which go away once the system is up.

Given the discussion in https://lkml.org/lkml/2019/1/28/1356 
I don't seem to be the only one, and it does not seem to be
Threadripper specific.

The first patch addresses presumably SMI interruptions, that occur
on my system at a 60 Hz frequency. They take too long, making the
existing code fail. The patch makes that code more resilient.
(These interruptions go away at some point during boot; also proven
by the fact, that I don't have any TSC issues, when kexecing into
a new kernel.)

The second patch prevents TSC going unstable when resuming from S3.
This may have a similar source, but is certainly more weird: the
TSC is observed to go backwards on CPU0 by about 200 to 500 cycles
compared to other CPUs every once in a while, as long as its sibling
(CPU16 in my case) hasn't been resumed yet. (I did some experiments
with CPU hotplug before and after suspend, but apart from reproducing
the issue and verifying the "fix", I got nowhere.)

The patches are against v4.20.

Jan H. Schönherr (2):
  x86/tsc: Allow quick PIT calibration despite interruptions
  cpu/hotplug: Unfreeze sibling CPU first on resume from S3

 arch/x86/kernel/tsc.c | 80 +++++++++++++++++++++++++------------------
 kernel/cpu.c          | 34 ++++++++++++------
 2 files changed, 70 insertions(+), 44 deletions(-)

-- 
2.19.2