linux-kernel - Re: [PATCH 00/15] KVM: x86: RDPID/RDTSCP fixes and uret MSR cleanups

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]

Date:   Wed, 5 May 2021 10:51:49 +0200
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Sean Christopherson <seanjc@...gle.com>
Cc:     Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Joerg Roedel <joro@...tes.org>, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org, Xiaoyao Li <xiaoyao.li@...el.com>,
        Reiji Watanabe <reijiw@...gle.com>
Subject: Re: [PATCH 00/15] KVM: x86: RDPID/RDTSCP fixes and uret MSR cleanups

On 04/05/21 19:17, Sean Christopherson wrote:
> This is a continuation of a less ambitious effort to unify MSR_TSC_AUX
> handling across SVM and VMX.  Reiji pointed out that MSR_TSC_AUX exists if
> RDTSCP *or* RDPID is supported, and things went downhill from there.
> 
> The first half of this series fixes a variety of RDTSCP and RDPID related
> bugs.
> 
> The second half of the series cleans up VMX's user return MSR framework
> and consolidates more of the uret logic into common x86.
> 
> The last two patches leverage the uret MSR cleanups to move MSR_TSC_AUX
> handling to common x86 and add sanity checks to guard against misreporting
> of RDPID and/or RDTSCP support.
> 
> This will conflict with my vCPU RESET/INIT cleanup series.  Feel free to
> punt the conflicts to me.
> 
> Other "fun" things to tackle:
> 
>   - The kernel proper also botches RDPID vs. RDTSCP, as MSR_TSC_AUX is
>     configured if RDTSCP is supported, but is consumed if RDPID is
>     supported.  I'll send this fix separately.
> 
>   - Commit 844d69c26d83 ("KVM: SVM: Delay restoration of host MSR_TSC_AUX
>     until return to userspace") unwittingly fixed a bug where KVM would
>     write MSR_TSC_AUX with the guest's value when svm->guest_state_loaded
>     is false, which could lead to running the host with the guest's value.
>     The bug only exists in 5.12 (maybe 5.11 too?), so crafting a fix for
>     stable won't be too awful.
> 
> Sean Christopherson (15):
>    KVM: VMX: Do not adverise RDPID if ENABLE_RDTSCP control is
>      unsupported
>    KVM: x86: Emulate RDPID only if RDTSCP is supported
>    KVM: SVM: Inject #UD on RDTSCP when it should be disabled in the guest
>    KVM: x86: Move RDPID emulation intercept to its own enum
>    KVM: VMX: Disable preemption when probing user return MSRs
>    KVM: SVM: Probe and load MSR_TSC_AUX regardless of RDTSCP support in
>      host
>    KVM: x86: Add support for RDPID without RDTSCP
>    KVM: VMX: Configure list of user return MSRs at module init
>    KVM: VMX: Use flag to indicate "active" uret MSRs instead of sorting
>      list
>    KVM: VMX: Use common x86's uret MSR list as the one true list
>    KVM: VMX: Disable loading of TSX_CTRL MSR the more conventional way
>    KVM: x86: Export the number of uret MSRs to vendor modules
>    KVM: x86: Move uret MSR slot management to common x86
>    KVM: x86: Tie Intel and AMD behavior for MSR_TSC_AUX to guest CPU
>      model
>    KVM: x86: Hide RDTSCP and RDPID if MSR_TSC_AUX probing failed
> 
>   arch/x86/include/asm/kvm_host.h |   9 +-
>   arch/x86/kvm/cpuid.c            |  18 ++-
>   arch/x86/kvm/emulate.c          |   2 +-
>   arch/x86/kvm/kvm_emulate.h      |   1 +
>   arch/x86/kvm/svm/svm.c          |  50 +++-----
>   arch/x86/kvm/vmx/vmx.c          | 217 ++++++++++++++++----------------
>   arch/x86/kvm/vmx/vmx.h          |  12 +-
>   arch/x86/kvm/x86.c              | 101 ++++++++++++---
>   8 files changed, 245 insertions(+), 165 deletions(-)
> 

Queued, thanks.

Paolo