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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <9be2f3c5-c72e-4f2d-acf8-2f70a513a2be@intel.com>
Date: Sun, 15 Sep 2024 00:14:56 -0500
From: "Xing, Cedric" <cedric.xing@...el.com>
To: James Bottomley <James.Bottomley@...senPartnership.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 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