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;
Message-ID: <35071cffb4acb117f1b4be2807c40792734bff89.camel@HansenPartnership.com>
Subject: Re: [PATCH 1/4] keys: Introduce tsm keys
From:   James Bottomley <James.Bottomley@HansenPartnership.com>
To:     Dionna Amalie Glaze <dionnaglaze@google.com>
Cc:     Dan Williams <dan.j.williams@intel.com>,
        Jarkko Sakkinen <jarkko@kernel.org>,
        Peter Gonda <pgonda@google.com>, dhowells@redhat.com,
        Kuppuswamy Sathyanarayanan 
        <sathyanarayanan.kuppuswamy@linux.intel.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Samuel Ortiz <sameo@rivosinc.com>, 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: <CAAH4kHaq0q0jGmpxskapo2J+oeWWBXuDd7RfgppO31+gnPSL6w@mail.gmail.com>
References: <169057265210.180586.7950140104251236598.stgit@dwillia2-xfh.jf.intel.com>
         <169057265801.180586.10867293237672839356.stgit@dwillia2-xfh.jf.intel.com>
         <CAMkAt6ot9zyUL9Ub-qYq+d9v-6rTft4ea2mUxp3o1s3GVFq7nw@mail.gmail.com>
         <CUHEL5OD3UR8.FRBWNF6MTP1Y@suppilovahvero>
         <64cc650233ef9_782a329489@dwillia2-xfh.jf.intel.com.notmuch>
         <CAAH4kHY_SjTdh55NBWn1KURCdjJUDM7nhi_gLpUhKKbRsVjX4Q@mail.gmail.com>
         <66161ce56ec783d1ec452a50b80b120bec8b56e8.camel@HansenPartnership.com>
         <CAAH4kHaq0q0jGmpxskapo2J+oeWWBXuDd7RfgppO31+gnPSL6w@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.4 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

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