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>
In-Reply-To: <169057267580.180586.15710177655506555147.stgit@dwillia2-xfh.jf.intel.com>
From:   Peter Gonda <pgonda@google.com>
Date:   Mon, 31 Jul 2023 10:45:36 -0600
Message-ID: <CAMkAt6r=r_utT6sd_LD-2rO-GpH4zd1D04p04P8WF51BKX-JMg@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"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Fri, Jul 28, 2023 at 1:31=E2=80=AFPM Dan Williams <dan.j.williams@intel.=
com> wrote:
>
> The sevguest driver was a first mover in the confidential computing
> space. As a first mover that afforded some leeway to build the driver
> without concern for common infrastructure.
>
> Now that sevguest is no longer a singleton [1] the common operation of
> building and transmitting attestation report blobs can / should be made
> common. In this model the so called "TSM-provider" implementations can
> share a common envelope ABI even if the contents of that envelope remain
> vendor-specific. When / if the industry agrees on an attestation record
> format, that definition can also fit in the same ABI. In the meantime
> the kernel's maintenance burden is reduced and collaboration on the
> commons is increased.
>
> Convert sevguest to use TSM keys to retrieve the blobs that the
> SNP_{GET,GET_EXT}_REPORT ioctls produce. The flow for retrieving the
> SNP_GET_REPORT blob via the keyctl utility would be:
>
>     dd if=3D/dev/urandom of=3Dpubkey bs=3D1 count=3D64
>     keyctl add tsm tsm_test "auth $(xxd -p -c 0 < pubkey) privlevel=3D2" =
@u
>     keyctl print $key_id | awk '{ print $3 }' | xxd -p -c 0 -r | hexdump =
-C
>
> ...while the SNP_GET_EXT_REPORT flow adds the "format=3Dextended" option
> to the request flow:
>
>     keyctl add tsm tsm_test "auth $(xxd -p -c 0 < pubkey) privlevel=3D2 f=
ormat=3Dextended" @u
>
> The output format from 'keyctl print' is:
>
>     <pubkey blob> <auth blob desc[:format]> <auth blob>
>
> ...where the blobs are hex encoded and the descriptor string is either
> "sev" or "sev:extended" in this case.
>
> Note, the Keys subsystem frontend for the functionality that
> SNP_GET_DERIVED_KEY represents is saved for follow-on work that likely
> needs to become a new trusted-keys type. The old ioctls can be lazily
> deprecated, the main motivation of this effort is to stop the
> proliferation of new ioctls, and to increase cross-vendor colloboration.

collaboration

>
> Note, only compile-tested.
>
> Link: http://lore.kernel.org/r/64961c3baf8ce_142af829436@dwillia2-xfh.jf.=
intel.com.notmuch [1]
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Tom Lendacky <thomas.lendacky@amd.com>
> Cc: Dionna Glaze <dionnaglaze@google.com>
> Cc: Brijesh Singh <brijesh.singh@amd.com>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> ---
>  drivers/virt/coco/sev-guest/Kconfig     |    2 +
>  drivers/virt/coco/sev-guest/sev-guest.c |   87 +++++++++++++++++++++++++=
++++++
>  2 files changed, 89 insertions(+)
>
> diff --git a/drivers/virt/coco/sev-guest/Kconfig b/drivers/virt/coco/sev-=
guest/Kconfig
> index da2d7ca531f0..bce43d4639ce 100644
> --- a/drivers/virt/coco/sev-guest/Kconfig
> +++ b/drivers/virt/coco/sev-guest/Kconfig
> @@ -2,9 +2,11 @@ config SEV_GUEST
>         tristate "AMD SEV Guest driver"
>         default m
>         depends on AMD_MEM_ENCRYPT
> +       depends on KEYS
>         select CRYPTO
>         select CRYPTO_AEAD2
>         select CRYPTO_GCM
> +       select TSM_KEYS
>         help
>           SEV-SNP firmware provides the guest a mechanism to communicate =
with
>           the PSP without risk from a malicious hypervisor who wishes to =
read,
> diff --git a/drivers/virt/coco/sev-guest/sev-guest.c b/drivers/virt/coco/=
sev-guest/sev-guest.c
> index f48c4764a7a2..2bdca268272d 100644
> --- a/drivers/virt/coco/sev-guest/sev-guest.c
> +++ b/drivers/virt/coco/sev-guest/sev-guest.c
> @@ -21,6 +21,7 @@
>  #include <linux/psp-sev.h>
>  #include <uapi/linux/sev-guest.h>
>  #include <uapi/linux/psp-sev.h>
> +#include <keys/tsm.h>
>
>  #include <asm/svm.h>
>  #include <asm/sev.h>
> @@ -769,6 +770,84 @@ static u8 *get_vmpck(int id, struct snp_secrets_page=
_layout *layout, u32 **seqno
>         return key;
>  }
>
> +static int sev_auth_new(struct tsm_key_payload *t, void *provider_data)
> +{
> +       struct snp_guest_dev *snp_dev =3D provider_data;
> +       const int report_size =3D SZ_16K;
> +       const int ext_size =3D
> +               PAGE_ALIGN_DOWN(TSM_DATA_MAX - report_size - sizeof(*t));
> +       int ret;
> +
> +       if (t->pubkey_len !=3D 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?

> +
> +       if (t->auth_blob_format[0] &&
> +           strcmp(t->auth_blob_format, "extended") !=3D 0)
> +               return -EINVAL;
> +
> +       if (t->auth_blob_format[0]) {
> +               u8 *buf __free(kvfree) =3D
> +                       kvzalloc(report_size + ext_size, GFP_KERNEL);
> +
> +               struct snp_ext_report_req req =3D {
> +                       .data =3D { .vmpl =3D t->privlevel },
> +                       .certs_address =3D (__u64)buf + report_size,
> +                       .certs_len =3D 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?

> +
> +               struct snp_guest_request_ioctl input =3D {
> +                       .msg_version =3D 1,
> +                       .req_data =3D (__u64) &req,
> +                       .resp_data =3D (__u64) buf,
> +               };
> +
> +               ret =3D get_ext_report(snp_dev, &input, SNP_KARG);
> +               if (ret)
> +                       return ret;
> +
> +               no_free_ptr(buf);
> +               t->auth_blob =3D buf;
> +               t->auth_blob_len =3D report_size + ext_size;
> +               t->auth_blob_desc =3D "sev";
> +       } else {
> +               u8 *buf __free(kvfree) =3D kvzalloc(report_size, GFP_KERN=
EL);
> +
> +               struct snp_report_req req =3D {
> +                       .vmpl =3D t->privlevel,
> +               };
> +               memcpy(&req.user_data, t->pubkey, 64);
> +
> +               struct snp_guest_request_ioctl input =3D {
> +                       .msg_version =3D 1,
> +                       .req_data =3D (__u64) &req,
> +                       .resp_data =3D (__u64) buf,
> +               };
> +
> +               ret =3D get_report(snp_dev, &input, SNP_KARG);
> +               if (ret)
> +                       return ret;
> +
> +               no_free_ptr(buf);
> +               t->auth_blob =3D buf;
> +               t->auth_blob_len =3D report_size;
> +               t->auth_blob_desc =3D "sev";
> +       }

Can we reduce the code duplication between the branches here?