On Thu, Oct 27, 2022 at 2:10 PM Peter Gonda <pgonda@xxxxxxxxxx> wrote: > > On Thu, Oct 27, 2022 at 12:06 PM Tom Lendacky <thomas.lendacky@xxxxxxx> 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@xxxxxxxxxx> > > > Reported-by: Peter Gonda <pgonda@xxxxxxxxxx> > > > Reviewed-by: Dionna Glaze <dionnaglaze@xxxxxxxxxx> > > > Cc: Borislav Petkov <bp@xxxxxxx> > > > Cc: Tom Lendacky <thomas.lendacky@xxxxxxx> > > > Cc: Michael Roth <michael.roth@xxxxxxx> > > > Cc: Haowen Bai <baihaowen@xxxxxxxxx> > > > Cc: Yang Yingliang <yangyingliang@xxxxxxxxxx> > > > Cc: Marc Orr <marcorr@xxxxxxxxxx> > > > Cc: David Rientjes <rientjes@xxxxxxxxxx> > > > Cc: Ashish Kalra <Ashish.Kalra@xxxxxxx> > > > Cc: linux-kernel@xxxxxxxxxxxxxxx > > > Cc: kvm@xxxxxxxxxxxxxxx > > > --- > > > 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? Actually we want the V2 version of this patch, which forces userspace to use 4 pages and therefore doesn't let a short userspace request corrupt the sequence numbers.
