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

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

[Tom Lendacky]

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

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

[Peter Gonda]

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
>

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

[Tom Lendacky]

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
>>

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

[Peter Gonda]

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
> >>