All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Peter Gonda <pgonda@google.com>
Cc: Ashish Kalra <Ashish.Kalra@amd.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Joerg Roedel <joro@8bytes.org>,
	"Lendacky, Thomas" <Thomas.Lendacky@amd.com>,
	Borislav Petkov <bp@alien8.de>,
	the arch/x86 maintainers <x86@kernel.org>,
	kvm list <kvm@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Andy Nguyen <theflow@google.com>,
	David Rientjes <rientjes@google.com>,
	John Allen <john.allen@amd.com>
Subject: Re: [PATCH] KVM: SVM: Use kzalloc for sev ioctl interfaces to prevent kernel memory leak.
Date: Fri, 13 May 2022 14:49:48 +0000	[thread overview]
Message-ID: <Yn5wDPPbVUysR4SF@google.com> (raw)
In-Reply-To: <CAMkAt6ogEpWf7J-OhXrPNw8KojwuLxUwfP6B+A7zrRHpNeX3uA@mail.gmail.com>

On Fri, May 13, 2022, Peter Gonda wrote:
> On Thu, May 12, 2022 at 4:23 PM Ashish Kalra <Ashish.Kalra@amd.com> wrote:
> >
> > From: Ashish Kalra <ashish.kalra@amd.com>
> >
> > For some sev ioctl interfaces, the length parameter that is passed maybe
> > less than or equal to SEV_FW_BLOB_MAX_SIZE, but larger than the data
> > that PSP firmware returns. In this case, kmalloc will allocate memory
> > that is the size of the input rather than the size of the data.
> > Since PSP firmware doesn't fully overwrite the allocated buffer, these
> > sev ioctl interface may return uninitialized kernel slab memory.
> >
> > Reported-by: Andy Nguyen <theflow@google.com>
> > Suggested-by: David Rientjes <rientjes@google.com>
> > Suggested-by: Peter Gonda <pgonda@google.com>
> > Cc: kvm@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
> > ---
> >  arch/x86/kvm/svm/sev.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> 
> Can we just update all the kmalloc()s that buffers get given to the
> PSP? For instance doesn't sev_send_update_data() have an issue?
> Reading the PSP spec it seems like a user can call this ioctl with a
> large hdr_len and the PSP will only fill out what's actually required
> like in these fixed up cases? This is assuming the PSP is written to
> spec (and just the current version). I'd rather have all of these
> instances updated.

Agreed, the kernel should explicitly initialize any copy_to_user() to source and
never rely on the PSP to fill the entire blob unless there's an ironclad guarantee
the entire struct/blob will be written.  E.g. it's probably ok to skip zeroing
"data" in sev_ioctl_do_platform_status(), but even then it might be wortwhile as
defense-in-depth.

Looking through other copy_to_user() calls:

  - "blob" in sev_ioctl_do_pek_csr()
  - "id_blob" in sev_ioctl_do_get_id2()
  - "pdh_blob" and "cert_blob" in sev_ioctl_do_pdh_export()

The last one is probably fine since the copy length comes from the PSP, but it's
not like these ioctls are performance critical...

	/* If we query the length, FW responded with expected data. */
	input.cert_chain_len = data.cert_chain_len;
	input.pdh_cert_len = data.pdh_cert_len;

  reply	other threads:[~2022-05-13 14:49 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-12 20:23 [PATCH] KVM: SVM: Use kzalloc for sev ioctl interfaces to prevent kernel memory leak Ashish Kalra
2022-05-12 22:02 ` Borislav Petkov
2022-05-13 13:37 ` Peter Gonda
2022-05-13 14:49   ` Sean Christopherson [this message]
2022-05-13 18:11     ` Ashish Kalra
2022-05-13 19:56       ` Sean Christopherson
2022-05-13 20:09       ` Peter Gonda
2022-05-13 20:47         ` Ashish Kalra

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=Yn5wDPPbVUysR4SF@google.com \
    --to=seanjc@google.com \
    --cc=Ashish.Kalra@amd.com \
    --cc=Thomas.Lendacky@amd.com \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=john.allen@amd.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=pgonda@google.com \
    --cc=rientjes@google.com \
    --cc=tglx@linutronix.de \
    --cc=theflow@google.com \
    --cc=x86@kernel.org \
    /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.