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

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

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