Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <169057265210.180586.7950140104251236598.stgit@dwillia2-xfh.jf.intel.com>
 <169057267580.180586.15710177655506555147.stgit@dwillia2-xfh.jf.intel.com>
 <CAMkAt6r=r_utT6sd_LD-2rO-GpH4zd1D04p04P8WF51BKX-JMg@mail.gmail.com> <64c7f7ddd777c_51ad029436@dwillia2-xfh.jf.intel.com.notmuch>
In-Reply-To: <64c7f7ddd777c_51ad029436@dwillia2-xfh.jf.intel.com.notmuch>
From:   Peter Gonda <pgonda@google.com>
Date:   Mon, 31 Jul 2023 12:28:07 -0600
Message-ID: <CAMkAt6rotv3UtPifmsRK6wQ-Gh0LjZTnkzK-Gce0SdRz-iN+gg@mail.gmail.com>
Subject: Re: [PATCH 4/4] virt: sevguest: Add TSM key support for SNP_{GET, GET_EXT}_REPORT
To:     Dan Williams <dan.j.williams@intel.com>
Cc:     dhowells@redhat.com, Borislav Petkov <bp@alien8.de>,
        Tom Lendacky <thomas.lendacky@amd.com>,
        Dionna Glaze <dionnaglaze@google.com>,
        Brijesh Singh <brijesh.singh@amd.com>, peterz@infradead.org,
        linux-coco@lists.linux.dev, keyrings@vger.kernel.org,
        x86@kernel.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

> > >
> > > +static int sev_auth_new(struct tsm_key_payload *t, void *provider_data)
> > > +{
> > > +       struct snp_guest_dev *snp_dev = provider_data;
> > > +       const int report_size = SZ_16K;
> > > +       const int ext_size =
> > > +               PAGE_ALIGN_DOWN(TSM_DATA_MAX - report_size - sizeof(*t));
> > > +       int ret;
> > > +
> > > +       if (t->pubkey_len != 64)
> > > +               return -EINVAL;
> >
> > Magic number?
> >
> > We only support asymmetric keys with public keys exactly equal to 64
> > bytes? Is that only p256? SNP uses p384 can we atleast allow that
> > curve too? But why not let userspace what key type they want to use?
>
> The kernel has no control here. See Table 20 MSG_REPORT_REQ Message
> Structure (https://www.amd.com/system/files/TechDocs/56860.pdf)
>
> ...only 64-byte payloads are accepted. I assume one could specify less
> than 64-bytes and zero-fill the rest, but that's a contract between the
> requester and the attester.

Great, we can then name this const.

Yes that's why typically the public key, any context, and nonce would
be hashed. Then we can include the digest into the report.

>
> >
> > > +
> > > +       if (t->auth_blob_format[0] &&
> > > +           strcmp(t->auth_blob_format, "extended") != 0)
> > > +               return -EINVAL;
> > > +
> > > +       if (t->auth_blob_format[0]) {
> > > +               u8 *buf __free(kvfree) =
> > > +                       kvzalloc(report_size + ext_size, GFP_KERNEL);
> > > +
> > > +               struct snp_ext_report_req req = {
> > > +                       .data = { .vmpl = t->privlevel },
> > > +                       .certs_address = (__u64)buf + report_size,
> > > +                       .certs_len = ext_size,
> > > +               };
> > > +               memcpy(&req.data.user_data, t->pubkey, 64);
> >
> > Again without any freshness from the remote party, of what use is this
> > attestation report?
>
> This interface is just marshaling the same data that could be retrieved
> via SNP_GET_REPORT ioctl on the sevguest chardev today. So I would point
> you back to vendor documentation for how this report is used. See "VM
> Launch and Attestation" here:
>
> https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthening-vm-isolation-with-integrity-protection-and-more.pdf
>
> I am just here to stanch the proliferation of new chardevs and new
> ioctls for this TSM-common operation. This effort was started when TDX
> patches showed up to take a 64-byte input payload and wrap it in a
> attestation report with its own chardev and ioctls.

The way this is currently setup suggests that a user should add a
pubkey with the 'keyctl add tsm ...'. But if a user does this as
described here it won't allow them to set up a secure protocol with a
remote entity.

I think a user could abuse the naming of this system to do the correct
thing by using 'keyctl add tsm ..' over data which is not a public key
and is instead a digest of some public key with additional protocol
data.