Message-ID: <f284ce29-6afe-40ce-ad81-b6b2cec9199c@intel.com>
Date: Thu, 12 Sep 2024 14:00: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/12/2024 7:15 AM, James Bottomley wrote:
> 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
> 
TPM predates TSM so has an existing implementation for sure.

> /sys/class/tpm/tpm0/pcr-<algo>/<n>
> 
> but they don't have much meaning without the log.
> 
Consolidating PCRs under TSM is not a requirement. But if it's 
desirable, it could be done. When it comes to the log, the assumption 
here is that we will switch log format after TSM takes over. The preboot 
log can stay where it is today. Yeah, it would be kinda ugly without a 
unified log, but the separation of semantics/storage is more important, 
because otherwise it will be very difficult to enable new applications.

>> 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?
> 
By "TCG2", I refer to the TPM PC client profile that defines the EV_* 
event types. I could be very wrong but I thought IMA content/event types 
had not been defined until CEL came along. Though both TCG2 and CEL were 
designed to be extensible, adding new event/content types would require 
revising the specs, which is a very high bar for new applications, and 
is one of the major reasons for introducing this new log format.

Regarding the IMA log, there are several options to integrate it into 
the TSM framework:

One straight forward option is to dedicate a RTMR for IMA use. This 
series allows off-log extension so nothing else (except mapping the PCR 
to the dedicated RTMR) needs changes.

The second option is to change IMA to use the new log format proposed 
here. Of course, it'd require more changes than the first option - I 
don't believe many people would like it at the moment.

The third option is "virtual measurement". We can define a virtual MR - 
say "mr_ima", to replace the current PCR. Then we back mr_ima by a real 
RTMR by logging the value extended to mr_ima. That is: when mr_ima is 
extended by value XYZ, an entry like "mr_ima extend <hash_algo>/XYZ" is 
logged to some native RTMR. Later on, the verifier can replay the RTMR 
log to calculate an mr_ima value that matches the IMA's log. This is 
actually an example of sharing an RTMR among multiple arbitrary 
applications. Events from different applications can be distinguished by 
the prefix ("mr_ima" in this example), and a layered verifier can be 
built - the bottom CC-specific layer verifies the integrity of the log 
without understanding IMA, then the top (CC-agnostic) layer verifies the 
IMA log using calculated "mr_ima" value by the bottom layer.

>> 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.

> 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).

-Cedric

Powered by blists - more mailing lists