From: Sean Christopherson <seanjc@google.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
Brijesh Singh <brijesh.singh@amd.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
John Allen <john.allen@amd.com>
Cc: Sean Christopherson <seanjc@google.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Wanpeng Li <wanpengli@tencent.com>,
Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
kvm@vger.kernel.org, linux-crypto@vger.kernel.org,
linux-kernel@vger.kernel.org, Borislav Petkov <bp@suse.de>,
Christophe Leroy <christophe.leroy@csgroup.eu>
Subject: [PATCH v2 4/8] crypto: ccp: Play nice with vmalloc'd memory for SEV command structs
Date: Tue, 6 Apr 2021 15:49:48 -0700 [thread overview]
Message-ID: <20210406224952.4177376-5-seanjc@google.com> (raw)
In-Reply-To: <20210406224952.4177376-1-seanjc@google.com>
Copy the incoming @data comman to an internal buffer so that callers can
put SEV command buffers on the stack without running afoul of
CONFIG_VMAP_STACK=y, i.e. without bombing on vmalloc'd pointers. As of
today, the largest supported command takes a 68 byte buffer, i.e. pretty
much every command can be put on the stack. Because sev_cmd_mutex is
held for the entirety of a transaction, only a single bounce buffer is
required.
Use the internal buffer unconditionally, as the majority of in-kernel
users will soon switch to using the stack. At that point, checking
virt_addr_valid() becomes (negligible) overhead in most cases, and
supporting both paths slightly increases complexity. Since the commands
are all quite small, the cost of the copies is insignificant compared to
the latency of communicating with the PSP.
Allocate a full page for the buffer as opportunistic preparation for
SEV-SNP, which requires the command buffer to be in firmware state for
commands that trigger memory writes from the PSP firmware. Using a full
page now will allow SEV-SNP support to simply transition the page as
needed.
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
drivers/crypto/ccp/sev-dev.c | 28 +++++++++++++++++++++++-----
drivers/crypto/ccp/sev-dev.h | 2 ++
2 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c
index 47a372e07223..4aedbdaffe90 100644
--- a/drivers/crypto/ccp/sev-dev.c
+++ b/drivers/crypto/ccp/sev-dev.c
@@ -155,12 +155,17 @@ static int __sev_do_cmd_locked(int cmd, void *data, int *psp_ret)
if (WARN_ON_ONCE(!data != !buf_len))
return -EINVAL;
- if (data && WARN_ON_ONCE(!virt_addr_valid(data)))
- return -EINVAL;
+ /*
+ * Copy the incoming data to driver's scratch buffer as __pa() will not
+ * work for some memory, e.g. vmalloc'd addresses, and @data may not be
+ * physically contiguous.
+ */
+ if (data)
+ memcpy(sev->cmd_buf, data, buf_len);
/* Get the physical address of the command buffer */
- phys_lsb = data ? lower_32_bits(__psp_pa(data)) : 0;
- phys_msb = data ? upper_32_bits(__psp_pa(data)) : 0;
+ phys_lsb = data ? lower_32_bits(__psp_pa(sev->cmd_buf)) : 0;
+ phys_msb = data ? upper_32_bits(__psp_pa(sev->cmd_buf)) : 0;
dev_dbg(sev->dev, "sev command id %#x buffer 0x%08x%08x timeout %us\n",
cmd, phys_msb, phys_lsb, psp_timeout);
@@ -204,6 +209,13 @@ static int __sev_do_cmd_locked(int cmd, void *data, int *psp_ret)
print_hex_dump_debug("(out): ", DUMP_PREFIX_OFFSET, 16, 2, data,
buf_len, false);
+ /*
+ * Copy potential output from the PSP back to data. Do this even on
+ * failure in case the caller wants to glean something from the error.
+ */
+ if (data)
+ memcpy(data, sev->cmd_buf, buf_len);
+
return ret;
}
@@ -984,6 +996,10 @@ int sev_dev_init(struct psp_device *psp)
if (!sev)
goto e_err;
+ sev->cmd_buf = (void *)devm_get_free_pages(dev, GFP_KERNEL, 0);
+ if (!sev->cmd_buf)
+ goto e_sev;
+
psp->sev_data = sev;
sev->dev = dev;
@@ -995,7 +1011,7 @@ int sev_dev_init(struct psp_device *psp)
if (!sev->vdata) {
ret = -ENODEV;
dev_err(dev, "sev: missing driver data\n");
- goto e_sev;
+ goto e_buf;
}
psp_set_sev_irq_handler(psp, sev_irq_handler, sev);
@@ -1010,6 +1026,8 @@ int sev_dev_init(struct psp_device *psp)
e_irq:
psp_clear_sev_irq_handler(psp);
+e_buf:
+ devm_free_pages(dev, (unsigned long)sev->cmd_buf);
e_sev:
devm_kfree(dev, sev);
e_err:
diff --git a/drivers/crypto/ccp/sev-dev.h b/drivers/crypto/ccp/sev-dev.h
index dd5c4fe82914..e1572f408577 100644
--- a/drivers/crypto/ccp/sev-dev.h
+++ b/drivers/crypto/ccp/sev-dev.h
@@ -52,6 +52,8 @@ struct sev_device {
u8 api_major;
u8 api_minor;
u8 build;
+
+ void *cmd_buf;
};
int sev_dev_init(struct psp_device *psp);
--
2.31.0.208.g409f899ff0-goog
next prev parent reply other threads:[~2021-04-06 22:50 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-06 22:49 [PATCH v2 0/8] ccp: KVM: SVM: Use stack for SEV command buffers Sean Christopherson
2021-04-06 22:49 ` [PATCH v2 1/8] crypto: ccp: Free SEV device if SEV init fails Sean Christopherson
2021-04-06 22:49 ` [PATCH v2 2/8] crypto: ccp: Detect and reject "invalid" addresses destined for PSP Sean Christopherson
2021-04-06 22:49 ` [PATCH v2 3/8] crypto: ccp: Reject SEV commands with mismatching command buffer Sean Christopherson
2021-04-06 22:49 ` Sean Christopherson [this message]
2021-04-06 22:49 ` [PATCH v2 5/8] crypto: ccp: Use the stack for small SEV command buffers Sean Christopherson
2021-04-07 5:18 ` Christophe Leroy
2021-04-17 12:40 ` Paolo Bonzini
2021-04-06 22:49 ` [PATCH v2 6/8] crypto: ccp: Use the stack and common buffer for status commands Sean Christopherson
2021-04-06 22:49 ` [PATCH v2 7/8] crypto: ccp: Use the stack and common buffer for INIT command Sean Christopherson
2021-04-07 5:20 ` Christophe Leroy
2021-04-17 12:42 ` Paolo Bonzini
2021-04-06 22:49 ` [PATCH v2 8/8] KVM: SVM: Allocate SEV command structures on local stack Sean Christopherson
2021-04-07 5:24 ` Christophe Leroy
2021-04-07 10:24 ` Borislav Petkov
2021-04-07 17:05 ` Sean Christopherson
2021-04-07 17:06 ` Christophe Leroy
2021-04-07 17:34 ` Borislav Petkov
2021-04-17 12:45 ` Paolo Bonzini
2021-04-07 17:16 ` [PATCH v2 0/8] ccp: KVM: SVM: Use stack for SEV command buffers Brijesh Singh
2021-04-07 18:00 ` Tom Lendacky
2021-04-15 16:09 ` Paolo Bonzini
2021-04-15 18:15 ` Tom Lendacky
2021-04-16 0:28 ` Herbert Xu
2021-04-17 12:47 ` 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=20210406224952.4177376-5-seanjc@google.com \
--to=seanjc@google.com \
--cc=bp@suse.de \
--cc=brijesh.singh@amd.com \
--cc=christophe.leroy@csgroup.eu \
--cc=jmattson@google.com \
--cc=john.allen@amd.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=thomas.lendacky@amd.com \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.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