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

[Xing, Cedric]

On 9/13/2024 7:58 AM, James Bottomley wrote:
> On Thu, 2024-09-12 at 14:00 -0500, Xing, Cedric wrote:
> > Unfortunately this is true, because this log format has different
> > design objectives than pretty much all existing log formats. Another
> > notable difference is this ABI is log oriented, vs. most existing log
> > formats are digest oriented. A log oriented design allows
> > applications to generate identical logs regardless of the underlying
> > CC arch.
>
> So you're saying in order to get this to work successfully you have to
> design a better log.  I'm afraid I now have to quote xkcd 927 to you:
>
> https://xkcd.com/927/
I read that long time ago. Really a great article!

Am I defining a new log format? Well, yes and no. I hope my response to 
another email from you could be helpful.

My intention is to separate semantics from storage of logs. So yes, I'm 
defining a new format for storing event records. But no, I'm not trying 
to impose any specific semantics. In fact, with the shared storage 
layer, we will be able to support a diverse range of semantics from 
various applications with just a single RTMR.

> > Using CEL terms, ELCD (Event Log Critical Data) could be easily
> > encapsulated in both TCG2 and CEL, but ELID (Event Log Informative
> > Data - i.e., lines starting with '#') is not. One use of ELID is to
> > support off-log extension, designed to help migrating existing
> > applications. The  `SYNC` lines (necessary after off-log extensions,
> > see Patch 2 for details) would also require special treatments from
> > the verifier. Therefore, converting this log to a TCG2 or CEL log is
> > NOT always doable. It'll be better to convert log format only when
> > needed (and before any off-log extensions have been done).
>
> You seem to be hung up on requiring a single log format.  That horse
> left the stable decades ago and isn't coming back (the CEL attempt to
> corral it was ultimately not successful).  I'm saying we accept that
> fact and simply expose and extend logs in whatever format they exist in
> today without forcing them to change.  

Can't agree more.

Therefore, to allow even more log formats (semantics), a common storage 
layer is desired to allow event records of different semantics to be 
mixed and separated at the same time. This is like a filesystem, on 
which data from different applications are mixed (on the block device) 
but still separated (at the file level).

-Cedric