linux-kernel - Re: [PATCH v2 2/2] KVM: SVM: Re-load current, not host, 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <b9b4bb21-47db-4282-8d4c-eedb836fbfb9@intel.com>
Date: Tue, 23 Sep 2025 12:05:18 +0800
From: Xiaoyao Li <xiaoyao.li@...el.com>
To: Sean Christopherson <seanjc@...gle.com>,
 Paolo Bonzini <pbonzini@...hat.com>
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
 Hou Wenlong <houwenlong.hwl@...group.com>,
 Lai Jiangshan <jiangshan.ljs@...group.com>
Subject: Re: [PATCH v2 2/2] KVM: SVM: Re-load current, not host, TSC_AUX on
 #VMEXIT from SEV-ES guest

On 9/20/2025 5:38 AM, Sean Christopherson wrote:
> From: Hou Wenlong <houwenlong.hwl@...group.com>
> 
> Prior to running an SEV-ES guest, set TSC_AUX in the host save area to the
> current value in hardware, as tracked by the user return infrastructure,
> instead of always loading the host's desired value for the CPU.  If the
> pCPU is also running a non-SEV-ES vCPU, loading the host's value on #VMEXIT
> could clobber the other vCPU's value, e.g. if the SEV-ES vCPU preempted
> the non-SEV-ES vCPU, in which case KVM expects the other vCPU's TSC_AUX
> value to be resident in hardware.
> 
> Note, unlike TDX, which blindly _zeroes_ TSC_AUX on TD-Exit, SEV-ES CPUs
> can load an arbitrary value.  Stuff the current value in the host save
> area instead of refreshing the user return cache so that KVM doesn't need
> to track whether or not the vCPU actually enterred the guest and thus
> loaded TSC_AUX from the host save area.
> 
> Fixes: 916e3e5f26ab ("KVM: SVM: Do not use user return MSR support for virtualized TSC_AUX")
> Cc: stable@...r.kernel.org
> Suggested-by: Lai Jiangshan <jiangshan.ljs@...group.com>
> Signed-off-by: Hou Wenlong <houwenlong.hwl@...group.com>
> [sean: handle the SEV-ES case in sev_es_prepare_switch_to_guest()]
> Signed-off-by: Sean Christopherson <seanjc@...gle.com>

Reviewed-by: Xiaoyao Li <xiaoyao.li@...el.com>

one nit below,

> ---
>   arch/x86/kvm/svm/sev.c | 14 +++++++++++++-
>   arch/x86/kvm/svm/svm.c | 26 +++++++-------------------
>   arch/x86/kvm/svm/svm.h |  4 +++-
>   3 files changed, 23 insertions(+), 21 deletions(-)
> 
> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> index cce48fff2e6c..95767b9d0d55 100644
> --- a/arch/x86/kvm/svm/sev.c
> +++ b/arch/x86/kvm/svm/sev.c
> @@ -4664,7 +4664,9 @@ int sev_vcpu_create(struct kvm_vcpu *vcpu)
>   	return 0;
>   }
>   
> -void sev_es_prepare_switch_to_guest(struct vcpu_svm *svm, struct sev_es_save_area *hostsa)
> +void sev_es_prepare_switch_to_guest(struct vcpu_svm *svm,
> +				    struct sev_es_save_area *hostsa,
> +				    int tsc_aux_uret_slot)

Passing the tsc_aux_uret_slot as paramter looks a bit ugly, how about 
externing it?