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

[James Bottomley]

On Wed, 2024-09-11 at 22:23 -0500, Xing, Cedric wrote:
> Hi James,
> 
> I would like to clarify that, even though the log format is
> incompatible with the existing TCG2 log format, nothing prevents TPM
> PCRs from being exposed through the TSM measurement framework.

Well, the PCRs are already exposed through 

/sys/class/tpm/tpm0/pcr-<algo>/<n>

but they don't have much meaning without the log.

> Please note that the existing event types in the TCG2 log format are 
> predominantly BIOS/firmware-oriented, which seldom makes sense for 
> applications in OS runtime. Consequently, most application-specific 
> events have to come under the EV_EVENT_TAG umbrella, which is 
> essentially arbitrary binary data with no specific format. Thus, I
> don't see much value in continuing the TCG2 log into OS runtime IMHO.

And the IMA log, which is runtime and isn't TCG2?

> The proposed log format aims to provide a framework for unambiguous 
> hashing while allowing application-defined events. Its primary design
> objective is to enable application-agnostic kernel/verifier to 
> hash/verify logs without understanding the event records, allowing 
> application-specific appraisers to be built on top (i.e., 
> semantics/storage separation). Both TCG2 and CEL formats rely on 
> event/content type to dictate what part of event data to hash, making
> semantics/storage separation impossible. Therefore, this proposed log
> format cannot accommodate entries from TCG2 or CEL logs due to that 
> design conflict. However, entries of this log can easily be
> encapsulated in TCG2 (as EV_ACTION entries) or CEL-JSON (a new
> content type string needs to be defined, like what systemd is doing
> today) logs.

But that's my complaint.  This specification:

   - Records are lines ending with `\n`.
   - Each record (line) is hashed in its entirety (excluding the
   trailing `\n`) and extended to the RTMR.
   - The log for an RTMR is stored at
   `/sys/kernel/tsm/<MR group name>/<RTMR name>/event_log` and consists
   of these delineated records.
   - Lines that are empty (containing only `\n`) or start with `#` are
   skipped (not hashed or extended).
   
Is completely incompatible with pretty much every current log format. 
Given you have fairly elaborate decorations for the register formats,
what's the problem with simply having a decoration for the log format? 
That way you can use the above incompatible log for your purpose but this
framework can support existing logs and expand to future ones as they come
along.  All this would mean initially to the code is adding the decoration
file (easy) and ensuring that append_event is handled by a log format
specific component, allowing for expansion.

James