From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bedivere.hansenpartnership.com (bedivere.hansenpartnership.com [96.44.175.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1461217D3 for ; Sat, 29 Jul 2023 18:17:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hansenpartnership.com; s=20151216; t=1690654641; bh=h5IfinV0go2IJt6uz9MUW3cuAh/IHb80AxpLJZogiEA=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:From; b=r9ACkFQJbUkVzN2cXL4f5hHR2nJvxeh1m6dsqEk6p49m5mkyejozaDoB5abuVpTue RWpUHOaHrjTshCNLUBjF3Pu4n38tdgoahXYxhPAOPlGEbKF3rzk+bCaTR/yAd6hvX3 /GaKZ8OaAmjYY3k9XUI6zQT1tQ2TUKXJ3UL4EeFQ= Received: from localhost (localhost [127.0.0.1]) by bedivere.hansenpartnership.com (Postfix) with ESMTP id 36D7B1281747; Sat, 29 Jul 2023 14:17:21 -0400 (EDT) Received: from bedivere.hansenpartnership.com ([127.0.0.1]) by localhost (bedivere.hansenpartnership.com [127.0.0.1]) (amavis, port 10024) with ESMTP id cMMexv2ufveb; Sat, 29 Jul 2023 14:17:21 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hansenpartnership.com; s=20151216; t=1690654641; bh=h5IfinV0go2IJt6uz9MUW3cuAh/IHb80AxpLJZogiEA=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:From; b=r9ACkFQJbUkVzN2cXL4f5hHR2nJvxeh1m6dsqEk6p49m5mkyejozaDoB5abuVpTue RWpUHOaHrjTshCNLUBjF3Pu4n38tdgoahXYxhPAOPlGEbKF3rzk+bCaTR/yAd6hvX3 /GaKZ8OaAmjYY3k9XUI6zQT1tQ2TUKXJ3UL4EeFQ= Received: from lingrow.int.hansenpartnership.com (unknown [IPv6:2601:5c4:4302:c21::a774]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by bedivere.hansenpartnership.com (Postfix) with ESMTPSA id BE7A01281269; Sat, 29 Jul 2023 14:17:19 -0400 (EDT) Message-ID: Subject: Re: [PATCH 0/4] keys: Introduce a keys frontend for attestation reports From: James Bottomley To: Dan Williams , dhowells@redhat.com Cc: Brijesh Singh , Kuppuswamy Sathyanarayanan , Peter Zijlstra , Tom Lendacky , Dionna Amalie Glaze , Borislav Petkov , Jarkko Sakkinen , Samuel Ortiz , Greg Kroah-Hartman , Andrew Morton , linux-coco@lists.linux.dev, keyrings@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org Date: Sat, 29 Jul 2023 14:17:18 -0400 In-Reply-To: <169057265210.180586.7950140104251236598.stgit@dwillia2-xfh.jf.intel.com> References: <169057265210.180586.7950140104251236598.stgit@dwillia2-xfh.jf.intel.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.4 Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit On Fri, 2023-07-28 at 12:30 -0700, Dan Williams wrote: > The bulk of the justification for this patch kit is in "[PATCH 1/4] > keys: Introduce tsm keys". The short summary is that the current > approach of adding new char devs and new ioctls, for what amounts to > the same functionality with minor formatting differences across > vendors, is untenable. Common concepts and the community benefit from > common infrastructure. I agree with this, but ... > Use Keys to build common infrastructure for confidential computing > attestation report blobs, convert sevguest to use it (leaving the > deprecation question alone for now), and pave the way for tdx-guest > and the eventual risc-v equivalent to use it in lieu of new ioctls. > > The sevguest conversion is only compile-tested. > > This submission is To:David since he needs to sign-off on the idea of > a new Keys type, the rest is up to the confidential-computing driver > maintainers to adopt. So why is this a keys subsystem thing? The keys in question cannot be used to do any key operations. It looks like a transport layer for attestation reports rather than anything key like. To give an analogy with the TPM: We do have a TPM interface to keys because it can be used for things like sealing (TPM stores a symmetric key) and even asymmetric operations (although TPM key support for that in 1.2 was just removed). However, in direct analogy with confidential computing: the TPM does have an attestation interface: TPM2_Quote and TPM2_Certify (among others) which is deliberately *not* wired in to the keys subsystem because the outputs are intended for external verifiers. If the goal is to unify the interface for transporting attestation reports, why not pull the attestation ioctls out of sevguest into something common? I also don't see in your interface where the nonce goes? Most attestation reports combine the report output with a user supplied nonce which gets added to the report signature to defend against replay. Finally, I can see the logic in using this to do key release, because the external relying entity usually wishes to transport secrets into the enclave, but the currently developing use case for that seems to be to use a confidential guest vTPM because then we can use the existing TPM disk key interfaces. Inventing something completely new isn't going to fly because all consumers have to be updated to use it (even though keys is a common interface, using key payloads isn't ... plus the systemd TPM disk encryption key doesn't even use kernel keys, it unwraps in userspace). James