[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAMkAt6q=3TZ5YKGkxqdzcakp8wudU9QNUtc5u35CCZj7HKNu8g@mail.gmail.com>
Date: Thu, 2 Mar 2023 07:48:26 -0700
From: Peter Gonda <pgonda@...gle.com>
To: Tom Lendacky <thomas.lendacky@....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 Thu, Feb 23, 2023 at 9:14 AM Tom Lendacky <thomas.lendacky@....com> wrote:
>
> 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>
Reviewed-by: Peter Gonda <pgonda@...gle.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
> >>
Powered by blists - more mailing lists