From: "Jörg Rödel" <joro@8bytes.org>
To: sashiko-reviews@lists.linux.dev
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH 1/4] kvm: svm: Streamline VMSA setting for VCPUs
Date: Thu, 11 Jun 2026 16:13:50 +0200 [thread overview]
Message-ID: <aiq_X6c5eEiuXIZs@8bytes.org> (raw)
In-Reply-To: <20260611125628.C61421F00893@smtp.kernel.org>
On Thu, Jun 11, 2026 at 12:56:28PM +0000, sashiko-bot@kernel.org wrote:
> [Severity: High]
> Does this sequence trigger an RMP violation?
>
> When an SEV-SNP guest provisions an AP and triggers svm_vmgexit_ap_creation(),
> KVM replaces the initial KVM-managed VMSA with the guest-provided one using
> sev_es_set_guest_vmsa(), which eagerly frees the old VMSA via
> sev_es_vcpu_free_vmsa().
>
> For SNP guests, the old VMSA page is in the VMSA_PRIVATE state and has been
> transitioned to the hardware VMSA state. To transition it back to shared
> memory, AMD architecture requires reclaiming the page via snp_page_reclaim()
> before issuing an RMPUPDATE.
Calling snp_page_reclaim() is only needed when the page is reclaimed before
LAUNCH_FINISH. Once the VM is running, which is is when it issues a
svm_vmgexit_ap_creation() request, then an RMPUPDATE is sufficient.
> [Severity: Critical]
> This is a pre-existing issue, but does dropping the page reference here allow
> a malicious guest to crash the host kernel?
>
> When a guest-provided VMSA is used for an AP, KVM resolves the GPA to a PFN
> and immediately drops its page reference here. The physical address is then
> programmed into the hardware VMCB.
>
> If a malicious guest issues a Page State Change request to transition this VMSA
> page back to shared memory, host userspace can handle this by calling
> fallocate(PUNCH_HOLE) on the guest_memfd. This would trigger
> sev_gmem_invalidate(), which attempts rmp_make_shared().
>
> Because the page is still in the VMSA state, rmp_make_shared() would fail.
> sev_gmem_invalidate() only prints a warning and proceeds, freeing the page
> back to the buddy allocator while its RMP entry is still guest-restricted.
>
> When the host buddy allocator reallocates and accesses this page, would it
> trigger an RMP violation and a host kernel panic?
This is not an issue because the RMPUPDATE will only fail when the VMSA is
currently used by a CPU in guest-mode (== its VCPU is running).
But in the sev_es_vcpu_free_vmsa() path this can not happen because this
function is always called in the context of the affecting VCPUs thread, which
makes sure that the VCPU is not in guest-mode.
-Joerg
next prev parent reply other threads:[~2026-06-11 14:13 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-11 12:35 [PATCH 0/4] KVM: SEV: Support direct setting of VMSA for SEV-SNP guests Jörg Rödel
2026-06-11 12:35 ` [PATCH 1/4] kvm: svm: Streamline VMSA setting for VCPUs Jörg Rödel
2026-06-11 12:56 ` sashiko-bot
2026-06-11 14:13 ` Jörg Rödel [this message]
2026-06-11 12:35 ` [PATCH 2/4] kvm: svm: Defer VMSA allocation to LAUNCH_FINISH stage Jörg Rödel
2026-06-11 12:58 ` sashiko-bot
2026-06-11 14:29 ` Jörg Rödel
2026-06-11 12:35 ` [PATCH 3/4] kvm: svm: Support guest-provided VMSA for launching Jörg Rödel
2026-06-11 13:05 ` sashiko-bot
2026-06-11 14:43 ` Jörg Rödel
2026-06-11 12:35 ` [PATCH 4/4] kvm: svm: Support KVM_SEV_SNP_PAGE_TYPE_VMSA at SNP_LAUNCH_UPDATE Jörg Rödel
2026-06-11 12:43 ` Sean Christopherson
2026-06-11 13:23 ` Jörg Rödel
2026-06-11 12:58 ` sashiko-bot
2026-06-11 15:23 ` Jörg Rödel
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=aiq_X6c5eEiuXIZs@8bytes.org \
--to=joro@8bytes.org \
--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.