All of lore.kernel.org
 help / color / mirror / Atom feed
From: Atish Patra <atish.patra@linux.dev>
To: Sean Christopherson <seanjc@google.com>
Cc: sashiko-reviews@lists.linux.dev, 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 18:08:08 -0700	[thread overview]
Message-ID: <30421bf9-dc93-4e30-aa63-1284ac79b0ba@linux.dev> (raw)
In-Reply-To: <ahoTEgTSVcEmUMvM@google.com>


On 5/29/26 3:28 PM, Sean Christopherson wrote:
> On Fri, May 29, 2026, Atish Patra wrote:
>>> 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.
> RMP #PFs on the VMSA will typically crash the host.  In this case, I would
> expect VMRUN to fault, which would trigger the BUG_ON() in kvm_spurious_fault().
> So assuming the "bad" VM can get far enough along to attempt VMRUN, this is
> likely fatal.

Ahh VMRUN would fault it self which would be bad. So no RMP #NPF.
Thanks for the clarification. I will send the v2 with the mirroring fix.

>> 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-30  1:08 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
2026-05-29 22:28       ` Sean Christopherson
2026-05-30  1:08         ` Atish Patra [this message]
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=30421bf9-dc93-4e30-aa63-1284ac79b0ba@linux.dev \
    --to=atish.patra@linux.dev \
    --cc=kvm@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=seanjc@google.com \
    /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.