From: Sean Christopherson <seanjc@google.com>
To: Michael Roth <michael.roth@amd.com>
Cc: Michael Roth <mdroth@utexas.edu>,
pbonzini@redhat.com, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, ashish.kalra@amd.com,
thomas.lendacky@amd.com, rick.p.edgecombe@intel.com
Subject: Re: [PATCH] KVM: SEV: Fix guest memory leak when handling guest requests
Date: Tue, 21 May 2024 09:58:36 -0700 [thread overview]
Message-ID: <ZkzSvPGass4z4u9p@google.com> (raw)
In-Reply-To: <qgzgdh7fqynpvu6gh6kox5rnixswtu2ewl3hiutohpndmbdo6x@kfwegt625uqh>
On Tue, May 21, 2024, Michael Roth wrote:
> On Tue, May 21, 2024 at 07:09:04AM -0700, Sean Christopherson wrote:
> > On Mon, May 20, 2024, Michael Roth wrote:
> > > On Mon, May 20, 2024 at 04:32:04PM -0700, Sean Christopherson wrote:
> > > > On Mon, May 20, 2024, Michael Roth wrote:
> > > > > But there is a possibility that the guest will attempt access the response
> > > > > PFN before/during that reporting and spin on an #NPF instead though. So
> > > > > maybe the safer more repeatable approach is to handle the error directly
> > > > > from KVM and propagate it to userspace.
> > > >
> > > > I was thinking more along the lines of KVM marking the VM as dead/bugged.
> > >
> > > In practice userspace will get an unhandled exit and kill the vcpu/guest,
> > > but we could additionally flag the guest as dead.
> >
> > Honest question, does it make sense from KVM to make the VM unusable? E.g. is
> > it feasible for userspace to keep running the VM? Does the page that's in a bad
> > state present any danger to the host?
>
> If the reclaim fails (which it shouldn't), then KVM has a unique situation
> where a non-gmem guest page is in a state. In theory, if the guest/userspace
> could somehow induce a reclaim failure, then can they potentially trick the
> host into trying to access that same page as a shared page and induce a
> host RMP #PF.
>
> So it does seem like a good idea to force the guest to stop executing. Then
> once the guest is fully destroyed the bad page will stay leaked so it
> won't affect subsequent activities.
>
> >
> > > Is there a existing mechanism for this?
> >
> > kvm_vm_dead()
>
> Nice, that would do the trick. I'll modify the logic to also call that
> after a reclaim failure.
Hmm, assuming there's no scenario where snp_page_reclaim() is expected fail, and
such a failure is always unrecoverable, e.g. has similar potential for inducing
host RMP #PFs, then KVM_BUG_ON() is more appropriate.
Ah, and there are already WARNs in the lower level helpers. Those WARNs should
be KVM_BUG_ON(), because AFAICT there's no scenario where letting the VM live on
is safe/sensible. And unless I'm missing something, snp_page_reclaim() should
do the private=>shared conversion, because the only reason to reclaim a page is
to move it back to shared state.
Lastly, I vote to rename host_rmp_make_shared() to kvm_rmp_make_shared() to make
it more obvious that it's a KVM helper, whereas rmp_make_shared() is a generic
kernel helper, i.e. _can't_ bug the VM because it doesn't (and shouldn't) have a
pointer to the VM.
E.g. end up with something like this:
/*
* Transition a page to hypervisor-owned/shared state in the RMP table. This
* should not fail under normal conditions, but leak the page should that
* happen since it will no longer be usable by the host due to RMP protections.
*/
static int kvm_rmp_make_shared(struct kvm *kvm, u64 pfn, enum pg_level level)
{
if (KVM_BUG_ON(rmp_make_shared(pfn, level), kvm)) {
snp_leak_pages(pfn, page_level_size(level) >> PAGE_SHIFT);
return -EIO;
}
return 0;
}
/*
* Certain page-states, such as Pre-Guest and Firmware pages (as documented
* in Chapter 5 of the SEV-SNP Firmware ABI under "Page States") cannot be
* directly transitioned back to normal/hypervisor-owned state via RMPUPDATE
* unless they are reclaimed first.
*
* Until they are reclaimed and subsequently transitioned via RMPUPDATE, they
* might not be usable by the host due to being set as immutable or still
* being associated with a guest ASID.
*
* Bug the VM and leak the page if reclaim fails, or if the RMP entry can't be
* converted back to shared, as the page is no longer usable due to RMP
* protections, and it's infeasible for the guest to continue on.
*/
static int snp_page_reclaim(struct kvm *kvm, u64 pfn)
{
struct sev_data_snp_page_reclaim data = {0};
int err;
data.paddr = __sme_set(pfn << PAGE_SHIFT);
if (KVM_BUG_ON(sev_do_cmd(SEV_CMD_SNP_PAGE_RECLAIM, &data, &err), kvm)) {
snp_leak_pages(pfn, 1);
return -EIO;
}
if (kvm_rmp_make_shared(kvm, pfn, PG_LEVEL_4K))
return -EIO;
return 0;
}
next prev parent reply other threads:[~2024-05-21 16:58 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-10 21:10 [PULL 00/19] KVM: Add AMD Secure Nested Paging (SEV-SNP) Hypervisor Support Michael Roth
2024-05-10 21:10 ` [PULL 01/19] KVM: MMU: Disable fast path if KVM_EXIT_MEMORY_FAULT is needed Michael Roth
2024-05-10 21:10 ` [PULL 02/19] KVM: SEV: Select KVM_GENERIC_PRIVATE_MEM when CONFIG_KVM_AMD_SEV=y Michael Roth
2024-05-10 21:10 ` [PULL 03/19] KVM: SEV: Add initial SEV-SNP support Michael Roth
2024-05-10 21:10 ` [PULL 04/19] KVM: SEV: Add KVM_SEV_SNP_LAUNCH_START command Michael Roth
2024-05-10 21:10 ` [PULL 05/19] KVM: SEV: Add KVM_SEV_SNP_LAUNCH_UPDATE command Michael Roth
2024-05-10 21:10 ` [PULL 06/19] KVM: SEV: Add KVM_SEV_SNP_LAUNCH_FINISH command Michael Roth
2024-05-10 21:10 ` [PULL 07/19] KVM: SEV: Add support to handle GHCB GPA register VMGEXIT Michael Roth
2024-05-10 21:10 ` [PULL 08/19] KVM: SEV: Add support to handle MSR based Page State Change VMGEXIT Michael Roth
2024-05-10 21:10 ` [PULL 09/19] KVM: SEV: Add support to handle " Michael Roth
2024-05-12 2:06 ` Michael Roth
2024-05-10 21:10 ` [PULL 10/19] KVM: SEV: Add support to handle RMP nested page faults Michael Roth
2024-05-10 21:10 ` [PULL 11/19] KVM: SEV: Support SEV-SNP AP Creation NAE event Michael Roth
2024-05-10 21:10 ` [PULL 12/19] KVM: SEV: Implement gmem hook for initializing private pages Michael Roth
2024-05-10 21:10 ` [PULL 13/19] KVM: SEV: Implement gmem hook for invalidating " Michael Roth
2024-05-15 22:32 ` Sean Christopherson
2024-05-16 3:11 ` Michael Roth
2024-05-21 16:55 ` Paolo Bonzini
2024-05-16 12:45 ` Paolo Bonzini
2024-05-10 21:10 ` [PULL 14/19] KVM: x86: Implement hook for determining max NPT mapping level Michael Roth
2024-05-10 21:10 ` [PULL 15/19] KVM: SEV: Avoid WBINVD for HVA-based MMU notifications for SNP Michael Roth
2024-05-10 21:10 ` [PULL 16/19] KVM: SVM: Add module parameter to enable SEV-SNP Michael Roth
2024-05-10 21:10 ` [PULL 17/19] KVM: SEV: Provide support for SNP_GUEST_REQUEST NAE event Michael Roth
2024-05-17 20:41 ` Edgecombe, Rick P
2024-05-17 22:01 ` Paolo Bonzini
2024-05-18 15:04 ` [PATCH] KVM: SEV: Fix guest memory leak when handling guest requests Michael Roth
2024-05-20 14:17 ` Sean Christopherson
2024-05-20 22:50 ` Michael Roth
2024-05-20 23:32 ` Sean Christopherson
2024-05-21 2:00 ` Michael Roth
2024-05-21 14:09 ` Sean Christopherson
2024-05-21 15:34 ` Michael Roth
2024-05-21 16:58 ` Sean Christopherson [this message]
2024-05-21 21:00 ` Michael Roth
2024-05-20 23:02 ` [PATCH v2] " Michael Roth
2024-05-10 21:10 ` [PULL 18/19] KVM: SEV: Provide support for SNP_EXTENDED_GUEST_REQUEST NAE event Michael Roth
2024-05-13 15:19 ` Nathan Chancellor
2024-05-13 16:53 ` Paolo Bonzini
2024-05-13 17:05 ` Michael Roth
2024-05-13 17:20 ` Paolo Bonzini
2024-05-13 21:18 ` Michael Roth
2024-05-10 21:10 ` [PULL 19/19] crypto: ccp: Add the SNP_VLEK_LOAD command Michael Roth
2024-05-12 7:14 ` [PULL 00/19] KVM: Add AMD Secure Nested Paging (SEV-SNP) Hypervisor Support Paolo Bonzini
2024-05-12 8:17 ` Paolo Bonzini
2024-05-13 1:06 ` Michael Roth
2024-05-13 22:08 ` Sean Christopherson
2024-05-31 3:22 ` Michael Roth
2024-06-03 16:44 ` Paolo Bonzini
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=ZkzSvPGass4z4u9p@google.com \
--to=seanjc@google.com \
--cc=ashish.kalra@amd.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mdroth@utexas.edu \
--cc=michael.roth@amd.com \
--cc=pbonzini@redhat.com \
--cc=rick.p.edgecombe@intel.com \
--cc=thomas.lendacky@amd.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox