MIME-Version: 1.0
References: <2afbcae6daf13f7ad5a4296692e0a0fe1bc1e4ee.1677083979.git.thomas.lendacky@amd.com>
In-Reply-To: <2afbcae6daf13f7ad5a4296692e0a0fe1bc1e4ee.1677083979.git.thomas.lendacky@amd.com>
From:   Peter Gonda <pgonda@google.com>
Date:   Wed, 22 Feb 2023 09:51:44 -0700
Message-ID: <CAMkAt6pqyOqVd_etLVfwrihEoc6XtS+BaVsV8x934rr4LmOCgw@mail.gmail.com>
Subject: Re: [RESEND PATCH] virt/sev-guest: Return -EIO if certificate buffer
 is not large enough
To:     Tom Lendacky <thomas.lendacky@amd.com>
Cc:     linux-kernel@vger.kernel.org, x86@kernel.org,
        Borislav Petkov <bp@alien8.de>,
        Larry Dewey <larry.dewey@amd.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

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
>