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

["Xing, Cedric" <cedric.xing@intel.com>]

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@intel.com 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.