Message ID | 169057267580.180586.15710177655506555147.stgit@dwillia2-xfh.jf.intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:918b:0:b0:3e4:2afc:c1 with SMTP id s11csp697129vqg; Fri, 28 Jul 2023 14:18:25 -0700 (PDT) X-Google-Smtp-Source: APBJJlHKbrGAmgAdNC4lsH6BIa707g6QmQzRUpvCee2EsZIp/lX2ku41XI1ZVcJXODfs11heNf7J X-Received: by 2002:a05:6a20:1e46:b0:132:cc63:b099 with SMTP id cy6-20020a056a201e4600b00132cc63b099mr2855036pzb.57.1690579104684; Fri, 28 Jul 2023 14:18:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1690579104; cv=none; d=google.com; s=arc-20160816; b=OQikFjEYKbd/zAX/AanYPVzOQ9P5uvwfF1TiKcV/u3ycKLHinGbH7mYui03UHMgtYO Cq7NOBrhyyk1kurvSPS4VF9qydPNaB4bHA3QwXZd1MxveV3Gkmv8P+byu0m/Ms4ZatDw Y06a80k4UC8soGbxLAm4JSyzzuwKuNslEeuqXpfpVR2XbKY3xJlcZXz1aJK76AR6WLJX yPzoRliF7BdlnZSgImXBnKuNchoRi/cWUkWjX4aQz/82XG5aSB6Ki3OHtWXX76it0sV0 1bDvICr3W4AliotkGtkDR5aY/pc6LksaXEwAY038TjnFF+glPltKezd+WOCxekxka0RM 5rCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:cc:to:from :subject:dkim-signature; bh=oXwNNlapPHd+Slp/b0Lu2jRYy3UDjso3u5csbsxFO+M=; fh=VUmUrHGFkTtXjIDywqDNwmDa+bm3A2NVF5lswC6u7/E=; b=vvzBhTOQyVoKZwXWZ/i/NbHZ4+QNhOFQAF/q+vRIqRppdpd6wESf/aGc81h666WgGt 5b85ikKCQmoSWOlbavo5ZSgKFsVukrRgSU/311bdsUBNJ+oQEoiKHFTwCWCcOTen9LOj qBkPoJd5RoH+lEx3SWOTeFc5nrH9idVkHMwVfR3bOYWr5hcRIIB+MmEx89DjzX9MMhnM InHFtVKmrYFEe11cGkCnqOhUlULxcnCcBdpohhYKHYKgcXfFK055scV+Ok4XNF157ga1 RgPyrlH9rVVGOUDe+9SfWQTmpCIaDVacbySm9MB/chBSxEGiya6wzVDGMhZT6Hb9fS1z Kt+g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=WTPuKzK5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id o15-20020a63a80f000000b0055793097dbesi3494480pgf.469.2023.07.28.14.18.11; Fri, 28 Jul 2023 14:18:24 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=WTPuKzK5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234402AbjG1Tbu (ORCPT <rfc822;hanasaki@gmail.com> + 99 others); Fri, 28 Jul 2023 15:31:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48996 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234254AbjG1Tbo (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 28 Jul 2023 15:31:44 -0400 Received: from mgamail.intel.com (unknown [192.55.52.151]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9A163268B; Fri, 28 Jul 2023 12:31:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1690572689; x=1722108689; h=subject:from:to:cc:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=ZmjmGLkvlIjh8KgnWd4vxpMs4lTuf4Wk7sbNKNMFp8U=; b=WTPuKzK5XobA6Sm+c1I2DA0Ff/Ssu2SMO+MSAgrAosreBiIJ6r6l6qn+ NWNYzIy8vylJU3LyQ2l3+rFunizuyWAXJDKE4JtEiNE0qQVkk7As0MZKY ETE3/+voU1ujHKhkCkTVuH+MPTpohdGM7m7G60n9Fx3xKy4MhirpO4v1N R91S96ijr9eUh8Yg/shnGiH5N4M7C3OfFFzEsOd6P3yqwZ3mRN45T4OVK /2WgxrXo93HQGZmm6M1Nx3usIUzHy9tBFFLSRCS6UrZwykg5A9JKMLw4t YOdm/YBUplC1oKzJjZkVHbbossCrDwVSF4x6dfcSBKCkUVMgFUDK4EX0f A==; X-IronPort-AV: E=McAfee;i="6600,9927,10785"; a="348958904" X-IronPort-AV: E=Sophos;i="6.01,238,1684825200"; d="scan'208";a="348958904" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jul 2023 12:31:16 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10785"; a="797529767" X-IronPort-AV: E=Sophos;i="6.01,238,1684825200"; d="scan'208";a="797529767" Received: from cheehong-laptop.gar.corp.intel.com (HELO dwillia2-xfh.jf.intel.com) ([10.212.158.179]) by fmsmga004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jul 2023 12:31:16 -0700 Subject: [PATCH 4/4] virt: sevguest: Add TSM key support for SNP_{GET, GET_EXT}_REPORT From: Dan Williams <dan.j.williams@intel.com> To: dhowells@redhat.com Cc: 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 Date: Fri, 28 Jul 2023 12:31:15 -0700 Message-ID: <169057267580.180586.15710177655506555147.stgit@dwillia2-xfh.jf.intel.com> In-Reply-To: <169057265210.180586.7950140104251236598.stgit@dwillia2-xfh.jf.intel.com> References: <169057265210.180586.7950140104251236598.stgit@dwillia2-xfh.jf.intel.com> User-Agent: StGit/0.18-3-g996c MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1772700674878521912 X-GMAIL-MSGID: 1772700674878521912 |
Series |
keys: Introduce a keys frontend for attestation reports
|
|
Commit Message
Dan Williams
July 28, 2023, 7:31 p.m. UTC
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=/dev/urandom of=pubkey bs=1 count=64
keyctl add tsm tsm_test "auth $(xxd -p -c 0 < pubkey) privlevel=2" @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=extended" option
to the request flow:
keyctl add tsm tsm_test "auth $(xxd -p -c 0 < pubkey) privlevel=2 format=extended" @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.
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(+)
Comments
On Fri, Jul 28, 2023 at 1:31 PM 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=/dev/urandom of=pubkey bs=1 count=64 > keyctl add tsm tsm_test "auth $(xxd -p -c 0 < pubkey) privlevel=2" @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=extended" option > to the request flow: > > keyctl add tsm tsm_test "auth $(xxd -p -c 0 < pubkey) privlevel=2 format=extended" @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 = 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? > + > + 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? > + > + struct snp_guest_request_ioctl input = { > + .msg_version = 1, > + .req_data = (__u64) &req, > + .resp_data = (__u64) buf, > + }; > + > + ret = get_ext_report(snp_dev, &input, SNP_KARG); > + if (ret) > + return ret; > + > + no_free_ptr(buf); > + t->auth_blob = buf; > + t->auth_blob_len = report_size + ext_size; > + t->auth_blob_desc = "sev"; > + } else { > + u8 *buf __free(kvfree) = kvzalloc(report_size, GFP_KERNEL); > + > + struct snp_report_req req = { > + .vmpl = t->privlevel, > + }; > + memcpy(&req.user_data, t->pubkey, 64); > + > + struct snp_guest_request_ioctl input = { > + .msg_version = 1, > + .req_data = (__u64) &req, > + .resp_data = (__u64) buf, > + }; > + > + ret = get_report(snp_dev, &input, SNP_KARG); > + if (ret) > + return ret; > + > + no_free_ptr(buf); > + t->auth_blob = buf; > + t->auth_blob_len = report_size; > + t->auth_blob_desc = "sev"; > + } Can we reduce the code duplication between the branches here?
Peter Gonda wrote: > On Fri, Jul 28, 2023 at 1:31 PM 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=/dev/urandom of=pubkey bs=1 count=64 > > keyctl add tsm tsm_test "auth $(xxd -p -c 0 < pubkey) privlevel=2" @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=extended" option > > to the request flow: > > > > keyctl add tsm tsm_test "auth $(xxd -p -c 0 < pubkey) privlevel=2 format=extended" @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 got it. > > > > > 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 = 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. > > > + > > + 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. > > > + > > + struct snp_guest_request_ioctl input = { > > + .msg_version = 1, > > + .req_data = (__u64) &req, > > + .resp_data = (__u64) buf, > > + }; > > + > > + ret = get_ext_report(snp_dev, &input, SNP_KARG); > > + if (ret) > > + return ret; > > + > > + no_free_ptr(buf); > > + t->auth_blob = buf; > > + t->auth_blob_len = report_size + ext_size; > > + t->auth_blob_desc = "sev"; > > + } else { > > + u8 *buf __free(kvfree) = kvzalloc(report_size, GFP_KERNEL); > > + > > + struct snp_report_req req = { > > + .vmpl = t->privlevel, > > + }; > > + memcpy(&req.user_data, t->pubkey, 64); > > + > > + struct snp_guest_request_ioctl input = { > > + .msg_version = 1, > > + .req_data = (__u64) &req, > > + .resp_data = (__u64) buf, > > + }; > > + > > + ret = get_report(snp_dev, &input, SNP_KARG); > > + if (ret) > > + return ret; > > + > > + no_free_ptr(buf); > > + t->auth_blob = buf; > > + t->auth_blob_len = report_size; > > + t->auth_blob_desc = "sev"; > > + } > > Can we reduce the code duplication between the branches here? I'll take a look.
> > > > > > +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.
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 = 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; + + 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); + + struct snp_guest_request_ioctl input = { + .msg_version = 1, + .req_data = (__u64) &req, + .resp_data = (__u64) buf, + }; + + ret = get_ext_report(snp_dev, &input, SNP_KARG); + if (ret) + return ret; + + no_free_ptr(buf); + t->auth_blob = buf; + t->auth_blob_len = report_size + ext_size; + t->auth_blob_desc = "sev"; + } else { + u8 *buf __free(kvfree) = kvzalloc(report_size, GFP_KERNEL); + + struct snp_report_req req = { + .vmpl = t->privlevel, + }; + memcpy(&req.user_data, t->pubkey, 64); + + struct snp_guest_request_ioctl input = { + .msg_version = 1, + .req_data = (__u64) &req, + .resp_data = (__u64) buf, + }; + + ret = get_report(snp_dev, &input, SNP_KARG); + if (ret) + return ret; + + no_free_ptr(buf); + t->auth_blob = buf; + t->auth_blob_len = report_size; + t->auth_blob_desc = "sev"; + } + + return 0; +} + +static const struct tsm_key_ops sev_tsm_ops = { + .name = KBUILD_MODNAME, + .module = THIS_MODULE, + .auth_new = sev_auth_new, +}; + +static void unregister_sev_tsm(void *data) +{ + unregister_tsm_provider(&sev_tsm_ops); +} + static int __init sev_guest_probe(struct platform_device *pdev) { struct snp_secrets_page_layout *layout; @@ -842,6 +921,14 @@ static int __init sev_guest_probe(struct platform_device *pdev) snp_dev->input.resp_gpa = __pa(snp_dev->response); snp_dev->input.data_gpa = __pa(snp_dev->certs_data); + ret = register_tsm_provider(&sev_tsm_ops, snp_dev); + if (ret) + goto e_free_cert_data; + + ret = devm_add_action_or_reset(&pdev->dev, unregister_sev_tsm, NULL); + if (ret) + goto e_free_cert_data; + ret = misc_register(misc); if (ret) goto e_free_cert_data;