drivers/virt/coco/sev-guest/sev-guest.c | 20 +++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-)
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@amd.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
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;
+
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
On Wed, Feb 22, 2023 at 9:39 AM Tom Lendacky <thomas.lendacky@amd.com> 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@amd.com> > Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> 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. > 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 >
On 2/22/23 10:51, Peter Gonda wrote: > On Wed, Feb 22, 2023 at 9:39 AM Tom Lendacky <thomas.lendacky@amd.com> 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@amd.com> >> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> > > 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 >>
On Thu, Feb 23, 2023 at 9:14 AM Tom Lendacky <thomas.lendacky@amd.com> wrote: > > On 2/22/23 10:51, Peter Gonda wrote: > > On Wed, Feb 22, 2023 at 9:39 AM Tom Lendacky <thomas.lendacky@amd.com> 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@amd.com> > >> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: Peter Gonda <pgonda@google.com> > > > > 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. Ah, I got it. Thanks Tom. > > 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 > >>
© 2016 - 2025 Red Hat, Inc.