Re: [PATCH RFC 0/3] tsm: Unified Measurement Register ABI for TVMs

[James Bottomley]

On Wed, 2024-09-11 at 21:46 +0800, Qinkun Bao wrote:
> On Wed, Sep 11, 2024 at 8:06 PM James Bottomley
> <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote:
> > 
> > On Tue, 2024-09-10 at 23:01 -0500, Xing, Cedric wrote:
> > > On 9/10/2024 12:09 PM, Jean-Philippe Brucker wrote:
> > > > Hi Cedric,
> > > > 
> > > > On Sat, Sep 07, 2024 at 11:56:18PM -0500, Cedric Xing wrote:
> > > > > Patch 2 introduces event log support for RTMRs, addressing
> > > > > the fact that the standalone values of RTMRs, which represent
> > > > > the cumulative digests of sequential events, are not fully
> > > > > informative on their own.
> > > > 
> > > > Would each event_log include the events that firmware wrote
> > > > before Linux?
> > > 
> > > No. The log format proposed here is textual and incompatible with
> > > TCG2 log format.
> > > 
> > > The proposed log format is based on the CoCo event log -
> > > https://github.com/confidential-containers/guest-components/issues/495
> > > .
> > 
> > Given that AMD is planning to use the SVSM-vTPM for post launch
> > measurements, not supporting TPMs in any form would make this Intel
> > only on x86 and thus not very "unified".  Microsoft also tends to
> > do attestations partly via the vTPM in its L1 openHCL component
> > (even for TDX) and thus would also have difficulty adopting this
> > proposal.
> > 
> 
> Hi James,
> 
> I don't think the patch should be blocked for not supporting the
> SVSM-vTPM and it is not an Intel only patch.

Actually, I'm not objecting to the patch not supporting the TPM, I'm
objecting to design choices, like the log, that make it much harder to
add TPM support later.  Realistically if you want a universal
measurement ABI, it has to work for physical systems as well, which
means TPM or DICE, since RTMR is a bit non-standard.

> 1. Not everyone prefers the SVSM-vTPM as it lacks the persistent
> storage and does not comply with TCG's TPM specifications. TPM is not
> just about the measurement.

I think you'll find an ephemeral TPM is TCG compliant: the NV is
actually an additional profile in the TCG specifications.

> Sealing and unsealing data is also a critical functionality for TPM.
> Treating thenSVSM-vTPM as a TPM misleads users and disrupts existing
> software based on TPMs. The SVSM-vTPM is not TPM. Just like
> Javascript is not Java.

I've already explained several times how sealing and unsealing can be
done with an ephemeral TPM. I'm not going to get into prejudices about
naming.

> 2. If our goal is to measure the boot chain and post-launch, the RTMR
> is an effective and straightforward method. We already support RTMR
> for TDX. For SNP, simulating the RTMRs in SVSM is very simple while
> implementing the SVSM-vTPM needs a lot of changes.

in the upstream, the vTPM is already done.  There's no current pull
request for RTMR emulation.

> The SVSM-vTPM significantly expands the TCB while offering limited
> security value enhancements compared to the RTMR.

So would every other feature on the coconut roadmap.

> 3. RTMR as a technology has been adopted widely. It is not an Intel
> only technology. The TDX CVMs on Google Cloud already support RTMRs.
> The TDX CVMs [1] on Alibaba Cloud supports RTMR as well. In terms of
> the attestation verifiers, the token from Intel ITA [2] and Microsoft
> Attestation Service [3] indicate they support RTMRs. The Ubuntu image
> [4] from Canonical enables RTMR by default.

So you think Intel should abandon its work on ephemeral vTPMs for TDX?

Regards,

James