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

[Dan Williams <dan.j.williams@intel.com>]

James Bottomley 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.

When I reviewed this with Cedric before hand I had been convinced that
this need not immediately trigger the "TPM vs RTMR" debate. Cedric can
jump in here where I get this wrong, but the thought is that once we
have this native RTMR interface with a cross-RTMR-vendor (Intel, RISCV,
ARM) common event-log it can be used to build virtual RTMRs / vTPM for
applications to use. In other words, use something like vtpm_proxy to
provide TPM services to applications, but proxy those those events to
this native RTMR backend.