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 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.