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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 23 Feb 2023 10:14:37 -0600
From:   Tom Lendacky <thomas.lendacky@....com>
To:     Peter Gonda <pgonda@...gle.com>
Cc:     linux-kernel@...r.kernel.org, x86@...nel.org,
        Borislav Petkov <bp@...en8.de>,
        Larry Dewey <larry.dewey@....com>
Subject: Re: [RESEND PATCH] virt/sev-guest: Return -EIO if certificate buffer
 is not large enough

On 2/22/23 10:51, Peter Gonda wrote:
> On Wed, Feb 22, 2023 at 9:39 AM Tom Lendacky <thomas.lendacky@....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@....com>
>> Signed-off-by: Tom Lendacky <thomas.lendacky@....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
>>