linux-kernel - Re: [PATCH v2 04/10] KVM: SVM: Don't change target vCPU state on AP Creation VMGEXIT error

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]

Message-ID: <a0f7bc73-aec3-4e05-b35e-b3095badf534@amd.com>
Date: Thu, 27 Feb 2025 11:25:31 +0100
From: "Gupta, Pankaj" <pankaj.gupta@....com>
To: Sean Christopherson <seanjc@...gle.com>,
 Paolo Bonzini <pbonzini@...hat.com>
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
 Naveen N Rao <naveen@...nel.org>, Kim Phillips <kim.phillips@....com>,
 Tom Lendacky <thomas.lendacky@....com>, Alexey Kardashevskiy <aik@....com>
Subject: Re: [PATCH v2 04/10] KVM: SVM: Don't change target vCPU state on AP
 Creation VMGEXIT error

On 2/27/2025 2:25 AM, Sean Christopherson wrote:
> If KVM rejects an AP Creation event, leave the target vCPU state as-is.
> Nothing in the GHCB suggests the hypervisor is *allowed* to muck with vCPU
> state on failure, let alone required to do so.  Furthermore, kicking only
> in the !ON_INIT case leads to divergent behavior, and even the "kick" case
> is non-deterministic.
> 
> E.g. if an ON_INIT request fails, the guest can successfully retry if the
> fixed AP Creation request is made prior to sending INIT.  And if a !ON_INIT
> fails, the guest can successfully retry if the fixed AP Creation request is
> handled before the target vCPU processes KVM's
> KVM_REQ_UPDATE_PROTECTED_GUEST_STATE.
> 
> Fixes: e366f92ea99e ("KVM: SEV: Support SEV-SNP AP Creation NAE event")
> Cc: stable@...r.kernel.org
> Reviewed-by: Tom Lendacky <thomas.lendacky@....com>
> Signed-off-by: Sean Christopherson <seanjc@...gle.com>

Reviewed-by: Pankaj Gupta <pankaj.gupta@....com>
> ---
>   arch/x86/kvm/svm/sev.c | 13 ++++++-------
>   1 file changed, 6 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> index 218738a360ba..9aad0dae3a80 100644
> --- a/arch/x86/kvm/svm/sev.c
> +++ b/arch/x86/kvm/svm/sev.c
> @@ -3957,16 +3957,12 @@ static int sev_snp_ap_creation(struct vcpu_svm *svm)
>   
>   	/*
>   	 * The target vCPU is valid, so the vCPU will be kicked unless the
> -	 * request is for CREATE_ON_INIT. For any errors at this stage, the
> -	 * kick will place the vCPU in an non-runnable state.
> +	 * request is for CREATE_ON_INIT.
>   	 */
>   	kick = true;
>   
>   	mutex_lock(&target_svm->sev_es.snp_vmsa_mutex);
>   
> -	target_svm->sev_es.snp_vmsa_gpa = INVALID_PAGE;
> -	target_svm->sev_es.snp_ap_waiting_for_reset = true;
> -
>   	/* Interrupt injection mode shouldn't change for AP creation */
>   	if (request < SVM_VMGEXIT_AP_DESTROY) {
>   		u64 sev_features;
> @@ -4012,20 +4008,23 @@ static int sev_snp_ap_creation(struct vcpu_svm *svm)
>   		target_svm->sev_es.snp_vmsa_gpa = svm->vmcb->control.exit_info_2;
>   		break;
>   	case SVM_VMGEXIT_AP_DESTROY:
> +		target_svm->sev_es.snp_vmsa_gpa = INVALID_PAGE;
>   		break;
>   	default:
>   		vcpu_unimpl(vcpu, "vmgexit: invalid AP creation request [%#x] from guest\n",
>   			    request);
>   		ret = -EINVAL;
> -		break;
> +		goto out;
>   	}
>   
> -out:
> +	target_svm->sev_es.snp_ap_waiting_for_reset = true;
> +
>   	if (kick) {
>   		kvm_make_request(KVM_REQ_UPDATE_PROTECTED_GUEST_STATE, target_vcpu);
>   		kvm_vcpu_kick(target_vcpu);
>   	}
>   
> +out:
>   	mutex_unlock(&target_svm->sev_es.snp_vmsa_mutex);
>   
>   	return ret;