Date:   Thu, 27 Oct 2022 14:10:47 -0600
From:   Peter Gonda <pgonda@...gle.com>
To:     Tom Lendacky <thomas.lendacky@....com>
Cc:     Dionna Glaze <dionnaglaze@...gle.com>,
        Borislav Petkov <bp@...e.de>,
        Michael Roth <michael.roth@....com>,
        Haowen Bai <baihaowen@...zu.com>,
        Yang Yingliang <yangyingliang@...wei.com>,
        Marc Orr <marcorr@...gle.com>,
        David Rientjes <rientjes@...gle.com>,
        Ashish Kalra <Ashish.Kalra@....com>,
        linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [PATCH V3 1/2] virt: sev: Prevent IV reuse in SNP guest driver

On Thu, Oct 27, 2022 at 12:06 PM Tom Lendacky <thomas.lendacky@....com> wrote:
>
> On 10/27/22 10:05, Peter Gonda wrote:
> > The ASP and an SNP guest use a series of AES-GCM keys called VMPCKs to
> > communicate securely with each other. The IV to this scheme is a
> > sequence number that both the ASP and the guest track. Currently this
> > sequence number in a guest request must exactly match the sequence
> > number tracked by the ASP. This means that if the guest sees an error
> > from the host during a request it can only retry that exact request or
> > disable the VMPCK to prevent an IV reuse. AES-GCM cannot tolerate IV
> > reuse see:
> > https://csrc.nist.gov/csrc/media/projects/block-cipher-techniques/documents/bcm/comments/800-38-series-drafts/gcm/joux_comments.pdf
> >
> > To handle userspace querying the cert_data length. Instead of requesting
> > the cert length from userspace use the size of the drivers allocated
> > shared buffer. Then copy that buffer to userspace, or give userspace an
> > error depending on the size of the buffer given by userspace.
> >
> > Fixes: fce96cf044308 ("virt: Add SEV-SNP guest driver")
> > Signed-off-by: Peter Gonda <pgonda@...gle.com>
> > Reported-by: Peter Gonda <pgonda@...gle.com>
> > Reviewed-by: Dionna Glaze <dionnaglaze@...gle.com>
> > Cc: Borislav Petkov <bp@...e.de>
> > Cc: Tom Lendacky <thomas.lendacky@....com>
> > Cc: Michael Roth <michael.roth@....com>
> > Cc: Haowen Bai <baihaowen@...zu.com>
> > Cc: Yang Yingliang <yangyingliang@...wei.com>
> > Cc: Marc Orr <marcorr@...gle.com>
> > Cc: David Rientjes <rientjes@...gle.com>
> > Cc: Ashish Kalra <Ashish.Kalra@....com>
> > Cc: linux-kernel@...r.kernel.org
> > Cc: kvm@...r.kernel.org
> > ---
> >   drivers/virt/coco/sev-guest/sev-guest.c | 93 ++++++++++++++++---------
> >   1 file changed, 62 insertions(+), 31 deletions(-)
> >
> > diff --git a/drivers/virt/coco/sev-guest/sev-guest.c b/drivers/virt/coco/sev-guest/sev-guest.c
> > index f422f9c58ba7..8c54ea84bc57 100644
> > --- a/drivers/virt/coco/sev-guest/sev-guest.c
> > +++ b/drivers/virt/coco/sev-guest/sev-guest.c
> > @@ -41,7 +41,7 @@ struct snp_guest_dev {
> >       struct device *dev;
> >       struct miscdevice misc;
> >
> > -     void *certs_data;
> > +     u8 (*certs_data)[SEV_FW_BLOB_MAX_SIZE];
> >       struct snp_guest_crypto *crypto;
> >       struct snp_guest_msg *request, *response;
> >       struct snp_secrets_page_layout *layout;
> > @@ -67,8 +67,27 @@ static bool is_vmpck_empty(struct snp_guest_dev *snp_dev)
> >       return true;
> >   }
> >
> > +/*
> > + * If we receive an error from the host or ASP we have two options. We can
> > + * either retry the exact same encrypted request or we can discontinue using the
> > + * VMPCK.
> > + *
> > + * This is because in the current encryption scheme GHCB v2 uses AES-GCM to
> > + * encrypt the requests. The IV for this scheme is the sequence number. GCM
> > + * cannot tolerate IV reuse.
> > + *
> > + * The ASP FW v1.51 only increments the sequence numbers on a successful
> > + * guest<->ASP back and forth and only accepts messages at its exact sequence
> > + * number.
> > + *
> > + * So if we were to reuse the sequence number the encryption scheme is
> > + * vulnerable. If we encrypt the sequence number for a fresh IV the ASP will
> > + * reject our request.
> > + */
> >   static void snp_disable_vmpck(struct snp_guest_dev *snp_dev)
> >   {
> > +     dev_alert(snp_dev->dev, "Disabling vmpck_id: %d to prevent IV reuse.\n",
> > +               vmpck_id);
> >       memzero_explicit(snp_dev->vmpck, VMPCK_KEY_LEN);
> >       snp_dev->vmpck = NULL;
> >   }
> > @@ -326,29 +345,29 @@ static int handle_guest_request(struct snp_guest_dev *snp_dev, u64 exit_code, in
> >       if (fw_err)
> >               *fw_err = err;
> >
> > -     if (rc)
> > -             return rc;
> > +     if (rc) {
> > +             dev_alert(snp_dev->dev,
> > +                       "Detected error from ASP request. rc: %d, fw_err: %llu\n",
> > +                       rc, *fw_err);
> > +             goto disable_vmpck;
> > +     }
>
> Realize that snp_issue_guest_request() will return -EIO in the case that
> the returned SW_EXITINFO2 value is SNP_GUEST_REQ_INVALID_LEN. So all the
> work you do below in get_ext_report() doesn't matter because you end up
> disabling the key here.
>
> So maybe this patch should be split up and parts of it added to the second
> patch (but that patch seems like it would still hit this issue because
> -EIO is still returned.
>

Ack I see that. My testing didn't catch this since I realized I didn't
actually load any certificate data into the host. After doing so my
testing catches this bug.

I agree with Dionna's comments on 2/2. My suggestion would be to keep
the constraint that either handle_guest_request() leaves the sequence
number in a good state or disables the VMPCK. After seeing her V4
series I suggest we take this patch and follow up on the certificate
querying with the further changes to snp_issue_guest_request().
Thoughts?

Powered by blists - more mailing lists