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 C13D21AA6B for ; Fri, 4 Aug 2023 17:12:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hansenpartnership.com; s=20151216; t=1691169130; bh=k/zttB4T2CScg/JHkOSPHBwHh+YE9cWs+BwYyqLser4=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:From; b=f9JvpJ3sVW4hPdpdMkW4G4H1qY0MpkDXtZ0kkXJLBYf0bDQlpQXP2PrpRVwO/wyeR V3KDEaKYOk+4l4rD7s26qs/AH6aCmJxFWUQduLByK+kWstN0O052ISCkVqiIaCIbnG 3ue1706uRljJyiQxRS7volAr5dsgXsw7w75kz5ak= Received: from localhost (localhost [127.0.0.1]) by bedivere.hansenpartnership.com (Postfix) with ESMTP id 7BF151280EA0; Fri, 4 Aug 2023 13:12:10 -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 fzGcu-YakGz3; Fri, 4 Aug 2023 13:12:10 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hansenpartnership.com; s=20151216; t=1691169130; bh=k/zttB4T2CScg/JHkOSPHBwHh+YE9cWs+BwYyqLser4=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:From; b=f9JvpJ3sVW4hPdpdMkW4G4H1qY0MpkDXtZ0kkXJLBYf0bDQlpQXP2PrpRVwO/wyeR V3KDEaKYOk+4l4rD7s26qs/AH6aCmJxFWUQduLByK+kWstN0O052ISCkVqiIaCIbnG 3ue1706uRljJyiQxRS7volAr5dsgXsw7w75kz5ak= Received: from lingrow.int.hansenpartnership.com (unknown [IPv6:2601:5c4:4302:c21::c14]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (2048 bits)) (Client did not present a certificate) by bedivere.hansenpartnership.com (Postfix) with ESMTPSA id 387A512804B6; Fri, 4 Aug 2023 13:12:09 -0400 (EDT) Message-ID: <35071cffb4acb117f1b4be2807c40792734bff89.camel@HansenPartnership.com> Subject: Re: [PATCH 1/4] keys: Introduce tsm keys From: James Bottomley To: Dionna Amalie Glaze Cc: Dan Williams , Jarkko Sakkinen , Peter Gonda , dhowells@redhat.com, Kuppuswamy Sathyanarayanan , Greg Kroah-Hartman , Samuel Ortiz , peterz@infradead.org, linux-coco@lists.linux.dev, keyrings@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org Date: Fri, 04 Aug 2023 13:12:07 -0400 In-Reply-To: References: <169057265210.180586.7950140104251236598.stgit@dwillia2-xfh.jf.intel.com> <169057265801.180586.10867293237672839356.stgit@dwillia2-xfh.jf.intel.com> <64cc650233ef9_782a329489@dwillia2-xfh.jf.intel.com.notmuch> <66161ce56ec783d1ec452a50b80b120bec8b56e8.camel@HansenPartnership.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: 8bit On Fri, 2023-08-04 at 10:07 -0700, Dionna Amalie Glaze wrote: > > > > Just on this one, it's already specified in the latest SVSM doc: > > > > https://lore.kernel.org/linux-coco/a2f31400-9e1c-c12a-ad7f-ea0265a12068@amd.com/ > > > > The Service Attestation Data on page 36-37.  It says TPMT_PUBLIC of > > the > > EK.  However, what it doesn't say is *which* EK.  I already sent in > > a > > comment saying it should be the TCG template for the P-256 curve > > EK. > > > > So asking the SVSM to give you the attestation report for the VTPM > > service binds the EK of the vTPM. > > > > Yes, thanks. It sounds like you have to ask the SVSM to certify the > EK separately from asking the TPM for a quote. That's right. > We can't rely entirely on the TPM API and avoid a sev-guest device > for talking to the SVSM. Yes, you have to make a SVSM service attestation call initially to validate the vTPM. > Or are you saying the SVSM attestation report will get encoded in > the x.509 EK certificate that the TPM API returns, such as the report > is in a cert extension? I'm less clear on how TPM software would > interpret the Issuer of that cert. There is no certificate. It's more like the Google Cloud: the SVSM vTPM has no EK cert, so you have to ask something else for validation of the EK, in this case a service attestation quote from the SVSM which confirms the binding of the current SVSM to the EK and then you use that EK pub to verify the vTPM. There's already experimental work to get this supported in Keylime, but doing it properly involves making the registrar EK validation mechanism pluggable. James