From: "Nikunj A. Dadhania" <nikunj@amd.com>
To: Tom Lendacky <thomas.lendacky@amd.com>,
linux-kernel@vger.kernel.org, x86@kernel.org
Cc: bp@alien8.de, dionnaglaze@google.com, pgonda@google.com,
seanjc@google.com, pbonzini@redhat.com, michael.roth@amd.com,
ketanch@iitk.ac.in
Subject: Re: [PATCH v2 03/11] virt: sev-guest: Add snp_guest_req structure
Date: Wed, 5 Apr 2023 11:01:32 +0530 [thread overview]
Message-ID: <639be6a6-929b-e27c-60a8-487b908812ce@amd.com> (raw)
In-Reply-To: <403cacf7-2694-d60d-1079-b8a3efcaebed@amd.com>
On 4/4/2023 1:29 AM, Tom Lendacky wrote:
> On 3/26/23 09:46, Nikunj A Dadhania wrote:
>> Add a snp_guest_req structure to simplify the function arguments. The
>> structure will be used to call the SNP Guest message request API
>> instead of passing a long list of parameters.
>>
>> Signed-off-by: Nikunj A Dadhania <nikunj@amd.com>
>> ---
>> drivers/virt/coco/sev-guest/sev-guest.c | 87 ++++++++++++++-----------
>> drivers/virt/coco/sev-guest/sev-guest.h | 19 ++++++
>> 2 files changed, 68 insertions(+), 38 deletions(-)
>>
>> diff --git a/drivers/virt/coco/sev-guest/sev-guest.c b/drivers/virt/coco/sev-guest/sev-guest.c
>> index 6ae197b57644..ec93dee330f2 100644
>> --- a/drivers/virt/coco/sev-guest/sev-guest.c
>> +++ b/drivers/virt/coco/sev-guest/sev-guest.c
>> @@ -60,16 +60,6 @@ static inline unsigned int get_ctx_authsize(struct snp_guest_dev *snp_dev)
>> return 0;
>> }
>> -static bool is_vmpck_empty(struct snp_guest_dev *snp_dev)
>> -{
>> - char zero_key[VMPCK_KEY_LEN] = {0};
>> -
>> - if (snp_dev->vmpck)
>> - return !memcmp(snp_dev->vmpck, zero_key, VMPCK_KEY_LEN);
>> -
>> - return true;
>> -}
>> -
>
> This change seems separate from the changes for snp_guest_req.
Sure, will create a separate patch.
>
>> /*
>> * If an error is received from the host or AMD Secure Processor (ASP) there
>> * are two options. Either retry the exact same encrypted request or discontinue
>> @@ -198,8 +188,9 @@ static int verify_and_dec_payload(struct snp_guest_dev *snp_dev, void *payload,
>> struct snp_guest_msg_hdr *resp_hdr = &resp->hdr;
>> struct aesgcm_ctx *ctx = snp_dev->ctx;
>> - dev_dbg(snp_dev->dev, "response [seqno %lld type %d version %d sz %d]\n",
>> - resp_hdr->msg_seqno, resp_hdr->msg_type, resp_hdr->msg_version, resp_hdr->msg_sz);
>> + pr_debug("response [seqno %lld type %d version %d sz %d]\n",
>> + resp_hdr->msg_seqno, resp_hdr->msg_type, resp_hdr->msg_version,
>> + resp_hdr->msg_sz);
>
> Again, not related to the purpose of this patch.
The idea was to get rid of dev_dbg for the movement, will do in a separate patch.
>
>> /* Verify that the sequence counter is incremented by 1 */
>> if (unlikely(resp_hdr->msg_seqno != (req_hdr->msg_seqno + 1)))
>> @@ -221,34 +212,34 @@ static int verify_and_dec_payload(struct snp_guest_dev *snp_dev, void *payload,
>> return dec_payload(ctx, resp, payload, resp_hdr->msg_sz);
>> }
>> -static int enc_payload(struct snp_guest_dev *snp_dev, u64 seqno, int version, u8 type,
>> - void *payload, size_t sz)
>> +static int enc_payload(struct snp_guest_dev *snp_dev, u64 seqno,
>> + struct snp_guest_req *req, u8 __vmpck_id)
>
> Can the vmpck_id be part of the snp_guest_req structure?
Sure, that should be possible.
>
>> {
>> - struct snp_guest_msg *req = snp_dev->request;
>> - struct snp_guest_msg_hdr *hdr = &req->hdr;
>> + struct snp_guest_msg *msg = snp_dev->request;
>> + struct snp_guest_msg_hdr *hdr = &msg->hdr;
>> - memset(req, 0, sizeof(*req));
>> + memset(msg, 0, sizeof(*msg));
>> hdr->algo = SNP_AEAD_AES_256_GCM;
>> hdr->hdr_version = MSG_HDR_VER;
>> hdr->hdr_sz = sizeof(*hdr);
>> - hdr->msg_type = type;
>> - hdr->msg_version = version;
>> + hdr->msg_type = req->msg_type;
>> + hdr->msg_version = req->msg_version;
>> hdr->msg_seqno = seqno;
>> - hdr->msg_vmpck = vmpck_id;
>> - hdr->msg_sz = sz;
>> + hdr->msg_vmpck = __vmpck_id;
>> + hdr->msg_sz = req->req_sz;
>> /* Verify the sequence number is non-zero */
>> if (!hdr->msg_seqno)
>> return -ENOSR;
>> - dev_dbg(snp_dev->dev, "request [seqno %lld type %d version %d sz %d]\n",
>> + pr_debug("request [seqno %lld type %d version %d sz %d]\n",
>
> Unrelated change.
Will move to a separate patch.
>
>> hdr->msg_seqno, hdr->msg_type, hdr->msg_version, hdr->msg_sz);
>> - return __enc_payload(snp_dev->ctx, req, payload, sz);
>> + return __enc_payload(snp_dev->ctx, msg, req->req_buf, req->req_sz);
>> }
>> -static int __handle_guest_request(struct snp_guest_dev *snp_dev, u64 exit_code, __u64 *fw_err)
>> +static int __handle_guest_request(struct snp_guest_dev *snp_dev, struct snp_guest_req *req)
>> {
>> unsigned long err = 0xff, override_err = 0;
>> unsigned long req_start = jiffies;
>> @@ -262,7 +253,7 @@ static int __handle_guest_request(struct snp_guest_dev *snp_dev, u64 exit_code,
>> * sequence number must be incremented or the VMPCK must be deleted to
>> * prevent reuse of the IV.
>> */
>> - rc = snp_issue_guest_request(exit_code, &snp_dev->input, &err);
>> + rc = snp_issue_guest_request(req->exit_code, &snp_dev->input, &err);
>> switch (rc) {
>> case -ENOSPC:
>> /*
>> @@ -273,7 +264,7 @@ static int __handle_guest_request(struct snp_guest_dev *snp_dev, u64 exit_code,
>> * IV reuse.
>> */
>> override_npages = snp_dev->input.data_npages;
>> - exit_code = SVM_VMGEXIT_GUEST_REQUEST;
>> + req->exit_code = SVM_VMGEXIT_GUEST_REQUEST;
>> /*
>> * Override the error to inform callers the given extended
>> @@ -314,8 +305,8 @@ static int __handle_guest_request(struct snp_guest_dev *snp_dev, u64 exit_code,
>> */
>> snp_inc_msg_seqno(snp_dev);
>> - if (fw_err)
>> - *fw_err = override_err ?: err;
>> + if (req->fw_err)
>> + *req->fw_err = override_err ?: err;
>> if (override_npages)
>> snp_dev->input.data_npages = override_npages;
>> @@ -332,13 +323,14 @@ static int __handle_guest_request(struct snp_guest_dev *snp_dev, u64 exit_code,
>> return rc;
>> }
>> -static int handle_guest_request(struct snp_guest_dev *snp_dev, u64 exit_code, int msg_ver,
>> - u8 type, void *req_buf, size_t req_sz, void *resp_buf,
>> - u32 resp_sz, __u64 *fw_err)
>> +static int snp_send_guest_request(struct snp_guest_dev *snp_dev, struct snp_guest_req *req)
>> {
>> u64 seqno;
>> int rc;
>> + if (!snp_dev || !req)
>> + return -ENODEV;
>
> This seems unrelated, at least the check for snp_dev. And looking at the only caller, a guest request is always provided. So this seems unnecessary - at least at this point in the series.
Right, not necessary here, but will be needed when sev-guest driver calls this after the movement to sev.c. Otherwise, I will need to add this in the movement patch 5/11.
>
>> +
>> /* Get message sequence and verify that its a non-zero */
>> seqno = snp_get_msg_seqno(snp_dev);
>> if (!seqno)
>> @@ -347,21 +339,22 @@ static int handle_guest_request(struct snp_guest_dev *snp_dev, u64 exit_code, in
>> memset(snp_dev->response, 0, sizeof(struct snp_guest_msg));
>> /* Encrypt the userspace provided payload */
>> - rc = enc_payload(snp_dev, seqno, msg_ver, type, req_buf, req_sz);
>> + rc = enc_payload(snp_dev, seqno, req, vmpck_id);
>> if (rc)
>> return rc;
>> - rc = __handle_guest_request(snp_dev, exit_code, fw_err);
>> + rc = __handle_guest_request(snp_dev, req);
>> if (rc) {
>> - if (rc == -EIO && *fw_err == SNP_GUEST_REQ_INVALID_LEN)
>> + if (rc == -EIO && *req->fw_err == SNP_GUEST_REQ_INVALID_LEN)
>> return rc;
>> - dev_alert(snp_dev->dev, "Detected error from ASP request. rc: %d, fw_err: %llu\n", rc, *fw_err);
>> + dev_alert(snp_dev->dev, "Detected error from ASP request. rc: %d, fw_err: %llu\n",
>> + rc, *req->fw_err);
>> snp_disable_vmpck(snp_dev);
>> return rc;
>> }
>> - rc = verify_and_dec_payload(snp_dev, resp_buf, resp_sz);
>> + rc = verify_and_dec_payload(snp_dev, req->resp_buf, req->resp_sz);
>
> Can't you just pass req here?
Yes, can do that.
>
>> if (rc) {
>> dev_alert(snp_dev->dev, "Detected unexpected decode failure from ASP. rc: %d\n", rc);
>> snp_disable_vmpck(snp_dev);
>> @@ -371,6 +364,24 @@ static int handle_guest_request(struct snp_guest_dev *snp_dev, u64 exit_code, in
>> return 0;
>> }
>> +
>> +static int handle_guest_request(struct snp_guest_dev *snp_dev, u64 exit_code, u8 msg_version,
>> + u8 msg_type, void *req_buf, size_t req_sz, void *resp_buf,
>> + u32 resp_sz, __u64 *fw_err)
>> +{
>> + struct snp_guest_req guest_req = {
>> + .msg_version = msg_version,
>> + .msg_type = msg_type,
>> + .req_buf = req_buf,
>> + .req_sz = req_sz,
>> + .resp_buf = resp_buf,
>> + .resp_sz = resp_sz,
>> + .fw_err = fw_err,
>> + .exit_code = exit_code,
>> + };
>
> Add a blank line here.
Sure.
Regards
Nikunj
next prev parent reply other threads:[~2023-04-05 5:31 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-26 14:46 [PATCH v2 00/11] Add Secure TSC support for SNP guests Nikunj A Dadhania
2023-03-26 14:46 ` [PATCH v2 01/11] virt: sev-guest: Use AES GCM crypto library Nikunj A Dadhania
2023-04-03 19:09 ` Tom Lendacky
2023-04-05 5:10 ` Nikunj A. Dadhania
2023-03-26 14:46 ` [PATCH v2 02/11] virt: sev-guest: Move mutex to SNP guest device structure Nikunj A Dadhania
2023-04-03 19:13 ` Tom Lendacky
2023-04-05 5:23 ` Nikunj A. Dadhania
2023-03-26 14:46 ` [PATCH v2 03/11] virt: sev-guest: Add snp_guest_req structure Nikunj A Dadhania
2023-04-03 19:59 ` Tom Lendacky
2023-04-05 5:31 ` Nikunj A. Dadhania [this message]
2023-03-26 14:46 ` [PATCH v2 04/11] virt: sev-guest: Add simplified helper to assign vmpck Nikunj A Dadhania
2023-04-03 20:26 ` Tom Lendacky
2023-04-05 6:18 ` Nikunj A. Dadhania
2023-04-10 16:31 ` Peter Gonda
2023-04-14 4:51 ` Nikunj A. Dadhania
2023-03-26 14:46 ` [PATCH v2 05/11] x86/sev: Move and reorganize sev guest request api Nikunj A Dadhania
2023-04-03 21:01 ` Tom Lendacky
2023-04-05 7:11 ` Nikunj A. Dadhania
2023-03-26 14:46 ` [PATCH v2 06/11] x86/mm: Add generic guest initialization hook Nikunj A Dadhania
2023-03-26 14:46 ` [PATCH v2 07/11] x86/sev: Change TSC MSR behavior for Secure TSC enabled guests Nikunj A Dadhania
2023-04-03 21:15 ` Tom Lendacky
2023-03-26 14:46 ` [PATCH v2 08/11] x86/sev: Add Secure TSC support for SNP guests Nikunj A Dadhania
2023-04-03 21:41 ` Tom Lendacky
2023-04-05 7:37 ` Nikunj A. Dadhania
2023-04-05 13:24 ` Tom Lendacky
2023-04-05 14:37 ` Nikunj A. Dadhania
2023-04-10 17:14 ` Peter Gonda
2023-04-14 5:10 ` Nikunj A. Dadhania
2023-03-26 14:46 ` [PATCH v2 09/11] x86/kvmclock: Use Secure TSC as clock if available Nikunj A Dadhania
2023-04-03 21:45 ` Tom Lendacky
2023-04-05 8:16 ` Nikunj A. Dadhania
2023-03-26 14:47 ` [PATCH v2 10/11] x86/tsc: Mark Secure TSC as reliable clocksource Nikunj A Dadhania
2023-03-26 14:47 ` [PATCH v2 11/11] x86/sev: Enable Secure TSC for SNP guests Nikunj A Dadhania
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=639be6a6-929b-e27c-60a8-487b908812ce@amd.com \
--to=nikunj@amd.com \
--cc=bp@alien8.de \
--cc=dionnaglaze@google.com \
--cc=ketanch@iitk.ac.in \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.roth@amd.com \
--cc=pbonzini@redhat.com \
--cc=pgonda@google.com \
--cc=seanjc@google.com \
--cc=thomas.lendacky@amd.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®