Message-ID: <6fa6084fb9157ec453854aa5b7d34bdfddc63a75.camel@HansenPartnership.com>
Date: Fri, 13 Sep 2024 08:58:37 -0400
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: "Xing, Cedric" <cedric.xing@...el.com>, Qinkun Bao <qinkun@...gle.com>
Cc: Jean-Philippe Brucker <jean-philippe@...aro.org>, Dan Williams
 <dan.j.williams@...el.com>, Samuel Ortiz <sameo@...osinc.com>, Lukas Wunner
 <lukas@...ner.de>, Dionna Amalie Glaze <dionnaglaze@...gle.com>, Mikko
 Ylinen <mikko.ylinen@...ux.intel.com>, Kuppuswamy Sathyanarayanan
 <sathyanarayanan.kuppuswamy@...ux.intel.com>, linux-kernel@...r.kernel.org,
  linux-coco@...ts.linux.dev, suzuki.poulose@....com, sami.mujawar@....com,
 Chong Cai <chongc@...gle.com>
Subject: Re: [PATCH RFC 0/3] tsm: Unified Measurement Register ABI for TVMs

On Thu, 2024-09-12 at 14:00 -0500, Xing, Cedric wrote:
> On 9/12/2024 7:15 AM, James Bottomley wrote:
> > On Wed, 2024-09-11 at 22:23 -0500, Xing, Cedric wrote:
[...]
> > > 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.
> 
> 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/

> > 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.
> > 
> 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.  I proposed a mechanism for doing
that here:

https://lore.kernel.org/linux-coco/86e6659bc8dd135491dc34bdb247caf05d8d2ad8.camel@HansenPartnership.com/

Which seems like it would work with pretty much every current
measurement tool (with minor modifications to change a few paths) and
even allow you to add your new log format if you insist.

Regards,

James

Powered by blists - more mailing lists