linux-kernel - [PATCH 0/2] x86/cpu: RDPID+MSR_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-next>] [day] [month] [year] [list]

Message-Id: <20210504225632.1532621-1-seanjc@google.com>
Date:   Tue,  4 May 2021 15:56:30 -0700
From:   Sean Christopherson <seanjc@...gle.com>
To:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        x86@...nel.org
Cc:     "H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org,
        Reiji Watanabe <reijiw@...gle.com>,
        Jim Mattson <jmattson@...gle.com>,
        Andy Lutomirski <luto@...nel.org>,
        Sean Christopherson <seanjc@...gle.com>
Subject: [PATCH 0/2] x86/cpu: RDPID+MSR_TSC_AUX fix and a cleanup

Fix a bug where MSR_TSC_AUX is left uninitialized in the theoretically
possible scenario where RDPID is supported by RDTSCP is not.  AFAIK, no
such CPUs exits, but both Intel and AMD architecturally allow RDPID and
MSR_TSC_AUX to exist without RDTSCP.

Found by inspection when cleaning up a similar mess in KVM.  Confirmed
the bug and verified the fix by running the problematic CPU model under
KVM (once KVM's even bigger trainwreck was fixed).

Sean Christopherson (2):
  x86/cpu: Initialize MSR_TSC_AUX if RDTSCP *or* RDPID is supported
  x86/cpu: Remove write_tsc() and write_rdtscp_aux() wrappers

 arch/x86/include/asm/msr.h   | 4 ----
 arch/x86/kernel/cpu/common.c | 4 ++--
 2 files changed, 2 insertions(+), 6 deletions(-)

-- 
2.31.1.527.g47e6f16901-goog