Re: [RESEND PATCH] virt/sev-guest: Return -EIO if certificate buffer is not large enough

From: Tom Lendacky
Date: Thu Feb 23 2023 - 11:14:48 EST


On 2/22/23 10:51, Peter Gonda wrote:
On Wed, Feb 22, 2023 at 9:39 AM Tom Lendacky <thomas.lendacky@xxxxxxx> wrote:

Commit 47894e0fa6a5 ("virt/sev-guest: Prevent IV reuse in the SNP guest
driver") changed the behavior associated with the return value when the
caller does not supply a large enough certificate buffer. Prior to the
commit a return value of -EIO was returned. Now a return value of 0 is
returned. This breaks the established ABI with the user.

Change the code to detect the buffer size error and return -EIO.

Fixes: 47894e0fa6a5 ("virt/sev-guest: Prevent IV reuse in the SNP guest driver")
Reported-by: Larry Dewey <larry.dewey@xxxxxxx>
Signed-off-by: Tom Lendacky <thomas.lendacky@xxxxxxx>

My bad. I wasn't testing the return value in this case.

Should Boris take this patch into the retry series?

---
drivers/virt/coco/sev-guest/sev-guest.c | 20 +++++++++++++++++---
1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/virt/coco/sev-guest/sev-guest.c b/drivers/virt/coco/sev-guest/sev-guest.c
index 4ec4174e05a3..7b4e9009f335 100644
--- a/drivers/virt/coco/sev-guest/sev-guest.c
+++ b/drivers/virt/coco/sev-guest/sev-guest.c
@@ -377,9 +377,26 @@ static int handle_guest_request(struct snp_guest_dev *snp_dev, u64 exit_code, in
snp_dev->input.data_npages = certs_npages;
}

+ /*
+ * Increment the message sequence number. There is no harm in doing
+ * this now because decryption uses the value stored in the response
+ * structure and any failure will wipe the VMPCK, preventing further
+ * use anyway.
+ */
+ snp_inc_msg_seqno(snp_dev);
+
if (fw_err)
*fw_err = err;

+ /*
+ * If an extended guest request was issued and the supplied certificate
+ * buffer was not large enough, a standard guest request was issued to
+ * prevent IV reuse. If the standard request was successful, return -EIO
+ * back to the caller as would have originally been returned.
+ */
+ if (!rc && err == SNP_GUEST_REQ_INVALID_LEN)
+ return -EIO;
+

Why not set 'ret = -EIO' and use disable_vmpck directly? That seems
more clear to me instead of failing on the next call.

We don't want to disable the VMPCK for this. This should go back to userspace with EIO and SNP_GUEST_REQ_INVALID_LEN, as it did prior to 47894e0fa6a5. Userspace then allocates a larger buffer and re-issues the request which should now succeed.

Thanks,
Tom


if (rc) {
dev_alert(snp_dev->dev,
"Detected error from ASP request. rc: %d, fw_err: %llu\n",
@@ -395,9 +412,6 @@ static int handle_guest_request(struct snp_guest_dev *snp_dev, u64 exit_code, in
goto disable_vmpck;
}

- /* Increment to new message sequence after payload decryption was successful. */
- snp_inc_msg_seqno(snp_dev);
-
return 0;

disable_vmpck:
--
2.39.1