Re: [RFC PATCH v1 0/4] tsm: Runtime measurement registers ABI

[Xing, Cedric]

On 1/21/2024 11:15 AM, Dan Williams wrote:
> Samuel Ortiz wrote:
> > On Thu, Jan 18, 2024 at 11:35:15AM +0800, biao.lu@xxxxxxxxx wrote:
> > > Samuel Ortiz wrote:
> > > > Some confidential computing architectures (Intel TDX, ARM CCA, RISC-V
> > > > CoVE) provide their guests with a set of measurements registers that can
> > > > be extended at runtime, i.e. after the initial, host-initiated
> > > > measurements of the TVM are finalized. Those runtime measurement
> > > > registers (RTMR) are isolated from the host accessible ones but TSMs
> > > > include them in their signed attestation reports.
> > > >
> > > > All architectures supporting RTMRs expose a similar interface to their
> > > > TVMs: An extension command/call that takes a measurement value and an
> > > > RTMR index to extend it with, and a readback command for reading an RTMR
> > > > value back (taking an RTMR index as an argument as well). This patch series
> > > > builds an architecture agnostic, configfs-based ABI for userspace to extend
> > > > and read RTMR values back. It extends the current TSM ops structure and
> > > > each confidential computing architecture can implement this extension to
> > > > provide RTMR support.
> > >
> > > Hi, Samuel
> > > The ABI does not include eventlog, but eventlog is usually used with RTMR.
> > > What do you think about how to implement eventlog?
> >
> > Since the event log is typically maintained in the firmware and not in
> > the TSM itself, I don't think we should expose e.g. an event log
> > extension ABI through the config-tsm one.
> > We could decide to check for an EFI CC protocol availability and extend
> > the event log when any RTMR gets extended, and that would be an
> > internal, not userspace visible operation. I'm not sure that this
> > would scale well with e.g. IMA (a lot more events than pre-OS boot
> > afaik).
>
> Another observation after chatting with my colleague Cedric is that the
> TPM layer that builds on RTMR can maintain an event log that forks from
> the RTMR log. I.e. instead of the TPM event log containig pre-OS events
> starting from 0, it would start from a golden point in the RTMR
> measurements.
That's right. What's needed in verification is the full history of how a 
measurement register's value was transitioned from A->B, which could be 
segmented as A->X then X->B and stored in separate event logs. Those 
event logs don't have to be maintained by the same entity or in the same 
format.