mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Tom Lendacky <thomas.lendacky@amd.com>
To: Peter Gonda <pgonda@google.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
	Borislav Petkov <bp@alien8.de>, Larry Dewey <larry.dewey@amd.com>
Subject: Re: [RESEND PATCH] virt/sev-guest: Return -EIO if certificate buffer is not large enough
Date: Thu, 23 Feb 2023 10:14:37 -0600	[thread overview]
Message-ID: <0c3a11bb-9036-2067-bf73-d18bb55c1225@amd.com> (raw)
In-Reply-To: <CAMkAt6pqyOqVd_etLVfwrihEoc6XtS+BaVsV8x934rr4LmOCgw@mail.gmail.com>

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

  reply	other threads:[~2023-02-23 16:14 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-22 16:39 Tom Lendacky
2023-02-22 16:51 ` Peter Gonda
2023-02-23 16:14   ` Tom Lendacky [this message]
2023-03-02 14:48     ` Peter Gonda

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=0c3a11bb-9036-2067-bf73-d18bb55c1225@amd.com \
    --to=thomas.lendacky@amd.com \
    --cc=bp@alien8.de \
    --cc=larry.dewey@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pgonda@google.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®