From: Tom Lendacky <thomas.lendacky@amd.com>
To: Sean Christopherson <seanjc@google.com>,
Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Michael Roth <michael.roth@amd.com>
Subject: Re: [PATCH] KVM: SEV: Reject non-positive effective lengths during LAUNCH_UPDATE
Date: Mon, 8 Sep 2025 16:35:58 -0500 [thread overview]
Message-ID: <b55f2ab4-da7c-5fed-adab-ceca54282ddb@amd.com> (raw)
In-Reply-To: <20250826233734.4011090-1-seanjc@google.com>
On 8/26/25 18:37, Sean Christopherson wrote:
> Check for an invalid length during LAUNCH_UPDATE at the start of
> snp_launch_update() instead of subtly relying on kvm_gmem_populate() to
> detect the bad state. Code that directly handles userspace input
> absolutely should sanitize those inputs; failure to do so is asking for
> bugs where KVM consumes an invalid "npages".
>
> Keep the check in gmem, but wrap it in a WARN to flag any bad usage by
> the caller.
>
> Note, this is technically an ABI change as KVM would previously allow a
> length of '0'. But allowing a length of '0' is nonsensical and creates
> pointless conundrums in KVM. E.g. an empty range is arguably neither
> private nor shared, but LAUNCH_UPDATE will fail if the starting gpa can't
> be made private. In practice, no known or well-behaved VMM passes a
> length of '0'.
>
> Cc: Thomas Lendacky <thomas.lendacky@amd.com>
> Cc: Michael Roth <michael.roth@amd.com>
> Signed-off-by: Sean Christopherson <seanjc@google.com>
> ---
>
> Compile tested only. Came across this when trying to figure out how to
> handle the batching of gmem post-populate calls.
>
> arch/x86/kvm/svm/sev.c | 2 ++
> virt/kvm/guest_memfd.c | 3 ++-
> 2 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> index f4381878a9e5..746a57bf1f71 100644
> --- a/arch/x86/kvm/svm/sev.c
> +++ b/arch/x86/kvm/svm/sev.c
> @@ -2360,6 +2360,8 @@ static int snp_launch_update(struct kvm *kvm, struct kvm_sev_cmd *argp)
> return -EINVAL;
>
> npages = params.len / PAGE_SIZE;
> + if (npages <= 0)
> + return -EINVAL;
Would it make sense to include a !params.len in the giant if check just
above this, e.g.:
if (!params.len || !PAGE_ALIGNED(params.len) || ...
?
That way everything related to checking "params" remains in the one
statement.
Thanks,
Tom
>
> /*
> * For each GFN that's being prepared as part of the initial guest
> diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
> index 7d85cc33c0bb..79552467add5 100644
> --- a/virt/kvm/guest_memfd.c
> +++ b/virt/kvm/guest_memfd.c
> @@ -639,7 +639,8 @@ long kvm_gmem_populate(struct kvm *kvm, gfn_t start_gfn, void __user *src, long
> long i;
>
> lockdep_assert_held(&kvm->slots_lock);
> - if (npages < 0)
> +
> + if (WARN_ON_ONCE(npages <= 0))
> return -EINVAL;
>
> slot = gfn_to_memslot(kvm, start_gfn);
>
> base-commit: ecbcc2461839e848970468b44db32282e5059925
next prev parent reply other threads:[~2025-09-08 21:36 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-26 23:37 [PATCH] KVM: SEV: Reject non-positive effective lengths during LAUNCH_UPDATE Sean Christopherson
2025-09-08 21:35 ` Tom Lendacky [this message]
2025-09-08 23:54 ` Sean Christopherson
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=b55f2ab4-da7c-5fed-adab-ceca54282ddb@amd.com \
--to=thomas.lendacky@amd.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.roth@amd.com \
--cc=pbonzini@redhat.com \
--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.