[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <66e227efbbf86_3263b294ba@dwillia2-xfh.jf.intel.com.notmuch>
Date: Wed, 11 Sep 2024 16:29:51 -0700
From: Dan Williams <dan.j.williams@...el.com>
To: James Bottomley <James.Bottomley@...senpartnership.com>, "Xing, Cedric"
<cedric.xing@...el.com>, Jean-Philippe Brucker <jean-philippe@...aro.org>
CC: Dan Williams <dan.j.williams@...el.com>, Samuel Ortiz
<sameo@...osinc.com>, Lukas Wunner <lukas@...ner.de>, Dionna Amalie Glaze
<dionnaglaze@...gle.com>, Qinkun Bao <qinkun@...gle.com>, Mikko Ylinen
<mikko.ylinen@...ux.intel.com>, Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@...ux.intel.com>, <linux-kernel@...r.kernel.org>,
<linux-coco@...ts.linux.dev>, <suzuki.poulose@....com>,
<sami.mujawar@....com>
Subject: Re: [PATCH RFC 0/3] tsm: Unified Measurement Register ABI for TVMs
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.
Powered by blists - more mailing lists