All of lore.kernel.org
 help / color / mirror / Atom feed
From: Atish Patra <atish.patra@linux.dev>
To: sashiko-reviews@lists.linux.dev
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH 1/2] KVM: SEV: Do not allow SEV-SNP VMs from intra-host migration
Date: Fri, 29 May 2026 13:41:53 -0700	[thread overview]
Message-ID: <709d9ca6-59bb-4f82-b48a-0aa67a4d6ba2@linux.dev> (raw)
In-Reply-To: <20260528235151.9E59E1F000E9@smtp.kernel.org>


On 5/28/26 4:51 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>
> Pre-existing issues:
> - [High] Incomplete protection against SEV-SNP VM state duplication in `sev_vm_copy_enc_context_from`.
> --
>
> commit 6c07753da8cad5a8ac0223da06cf2b84411e6fbf
> Author: Atish Patra <atishp@meta.com>
>
>      KVM: SEV: Do not allow SEV-SNP VMs from intra-host migration
>      
>      The intra-host migration feature is not fully implemented for SEV-SNP
>      VMs which require additional SNP-specific state such as guest_req_mutex,
>      guest_req_buf, and guest_resp_buf to be transferred or initialized on
>      the destination.
>
>> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
>> index c2126b3c30724..aff6a0cf5bfe8 100644
>> --- a/arch/x86/kvm/svm/sev.c
>> +++ b/arch/x86/kvm/svm/sev.c
>> @@ -2142,7 +2142,8 @@ int sev_vm_move_enc_context_from(struct kvm *kvm, unsigned int source_fd)
>>   		return ret;
>>   
>>   	if (kvm->arch.vm_type != source_kvm->arch.vm_type ||
>> -	    sev_guest(kvm) || !sev_guest(source_kvm)) {
>> +	    sev_guest(kvm) || !sev_guest(source_kvm) ||
>> +	    sev_snp_guest(source_kvm)) {
> [Severity: High]
> This isn't a bug introduced by this patch, but does
> sev_vm_copy_enc_context_from() also need a similar check to block SEV-SNP
> VMs from VM mirroring?
>
> If userspace creates a mirror of an SNP VM, sev_vm_copy_enc_context_from()
> copies its encryption context but fails to copy vmsa_features:
>
> arch/x86/kvm/svm/sev.c:sev_vm_copy_enc_context_from() {
>      ...
>      mirror_sev->enc_context_owner = source_kvm;
>      mirror_sev->active = true;
>      mirror_sev->asid = source_sev->asid;
>      mirror_sev->fd = source_sev->fd;
>      mirror_sev->es_active = source_sev->es_active;
>      mirror_sev->need_init = false;
>      mirror_sev->handle = source_sev->handle;
>      ...
> }
>
> Because the mirror's vmsa_features is zero, KVM treats the mirror VM as a
> standard SEV-ES VM (since ____sev_snp_guest() will evaluate to false).
>
> When vCPUs are created for the mirror VM, KVM allocates standard SEV-ES
> VMSAs and fails to perform SNP-specific initialization, such as registering
> the VMSA pages in the RMP via SEV_CMD_SNP_LAUNCH_UPDATE.
>
> When KVM executes VMRUN for the mirror VM's vCPU, the hardware evaluates an
> ASID bound to SNP execution using an invalid, non-RMP-registered VMSA page.
> Will this trigger an RMP #NPF (Nested Page Fault) on the host hypervisor,
> leading to an unhandled hypervisor crash and denial of service?

Nice catch! I don't think it will lead to hypervisor crash though. As 
per my understanding, the fault on VMSA
page would be sent to user space and just a VM instance will crash which 
is not that critical.

Having said that, we should close the gap for such mistakes from VMM 
side though by rejecting mirroring
of sev-snp VMs. I will add a patch and update the migration kselftest as 
well for sanity checking.

>>   		ret = -EINVAL;
>>   		goto out_unlock;
>>   	}

  reply	other threads:[~2026-05-29 20:41 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-28 23:11 [PATCH 0/2] KVM: Miscallenous SEV/SNP fixes Atish Patra
2026-05-28 23:11 ` [PATCH 1/2] KVM: SEV: Do not allow SEV-SNP VMs from intra-host migration Atish Patra
2026-05-28 23:51   ` sashiko-bot
2026-05-29 20:41     ` Atish Patra [this message]
2026-05-29 22:28       ` Sean Christopherson
2026-05-30  1:08         ` Atish Patra
2026-05-28 23:11 ` [PATCH 2/2] crypto: ccp: Fix possible deadlock in SEV init failure path Atish Patra
2026-05-29  0:51   ` sashiko-bot
2026-05-30  0:53     ` Atish Patra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=709d9ca6-59bb-4f82-b48a-0aa67a4d6ba2@linux.dev \
    --to=atish.patra@linux.dev \
    --cc=kvm@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.