Received-SPF: pass (google.com: domain of linux-kernel+bounces-64896-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Message-ID: <ef770532-6db6-4262-8225-2d3ee09b7d23@intel.com>
Date: Wed, 14 Feb 2024 00:54:09 -0800
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v2 0/4] tsm: Runtime measurement registers ABI
Content-Language: en-US
To: James Bottomley <James.Bottomley@HansenPartnership.com>, Dan Williams
	<dan.j.williams@intel.com>, Kuppuswamy Sathyanarayanan
	<sathyanarayanan.kuppuswamy@linux.intel.com>, Dan Middleton
	<dan.middleton@linux.intel.com>, Samuel Ortiz <sameo@rivosinc.com>
CC: Qinkun Bao <qinkun@google.com>, "Yao, Jiewen" <jiewen.yao@intel.com>,
	Dionna Amalie Glaze <dionnaglaze@google.com>, <biao.lu@intel.com>,
	<linux-coco@lists.linux.dev>, <linux-integrity@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>
References: <a255bc36-2438-41b7-b304-bcf7a6628bef@linux.intel.com>
 <42e14f74d3819c95fdb97cd2e9b2829dcb1b1563.camel@HansenPartnership.com>
 <1557f98a-3d52-4a02-992b-4401c7c85dd7@linux.intel.com>
 <85b7a4a679eada1d17b311bf004c2d9e18ab5cd3.camel@HansenPartnership.com>
 <b8140cc8-a56b-40f6-a593-7be49db14c77@intel.com>
 <fe1722c3618a8216cb53b8fd3f1b7cbb6fdff5a0.camel@HansenPartnership.com>
 <65c2e4aa54a0_d4122947f@dwillia2-mobl3.amr.corp.intel.com.notmuch>
 <22088ed3-51a4-415f-932c-db84c92a2812@intel.com>
 <527da630-4952-4b1d-80c0-5a87997ff9fd@linux.intel.com>
 <332775d7218843d6cc168c963d76e6841eab5d5b.camel@HansenPartnership.com>
 <65c691e13a50d_afa42948a@dwillia2-xfh.jf.intel.com.notmuch>
 <226df539-b3f4-4099-b6a6-293fa200c536@intel.com>
 <982e19fcd71c41a162ba664281eb0a68d9dc960c.camel@HansenPartnership.com>
From: "Xing, Cedric" <cedric.xing@intel.com>
In-Reply-To: <982e19fcd71c41a162ba664281eb0a68d9dc960c.camel@HansenPartnership.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Q2RLZmFxeVlRQ2VleGhLZFMzNW94ay9tRFlTN0t2bzRxNjhoSnQzZ1NxV1ZT?=
 =?utf-8?B?eXFHanpKakpRa1ZiWE1ibitnZTNlL2xoelhKOTdhWmdOek5BeFo2QmJLNW40?=
 =?utf-8?B?ZG9yenRHVytFeEJRbEpaTnhDWURlZ0FYSHREcFNsK1A2WGp6ZXR0bTF5UXFP?=
 =?utf-8?B?SE5ia0NQWHBWYW1YdjcvekxCMTNGSG13eHRJdjNHT0Z5MkplTkh3eDcxazEx?=
 =?utf-8?B?Tk9ONmRhczRGZHR5MmJyL0hZRURqRmw2Z1V4bko4MXRWUys0MlRwdXRSQlEv?=
 =?utf-8?B?S0dXRmhKUUdWTE5kWEkveGljT1NzSlZ1ODZwK0tleERQUVU4REZkN1liWHlH?=
 =?utf-8?B?S0lwMkRWNVd6UE4rTHlOV2pBWWpjNTI3eTJ1Z29iLzRPU3hnckpxOGVTTUNa?=
 =?utf-8?B?Vjc0TW80MHgramJJbTdOODZNdG91aTF3ZUF0U1JOaFk1dGh6MCtUSmpzTnV4?=
 =?utf-8?B?RWVYN3AzbnJuVmRaakJYMU1pS2ovcWpnRXhNZFBmZVdKQ0FBUUdxNS9UZjhz?=
 =?utf-8?B?M2lOdXI4aTk4T2xyWUo1OUFKSWVnQTFNbGV2SGlRbjhqOC9uR2k2c0tkYmtl?=
 =?utf-8?B?NjFjdFEyazN1VnVnbnJRSldETWk5Q3p4WHEvT1VyOTk1WHkzMnYrbzZmQWtS?=
 =?utf-8?B?Z1o0RVdCWWZCTHNPK0djOXU5eDc4cTRTRDVQeDhieE9KcEtjeldZcHdXakNG?=
 =?utf-8?B?NGgwbTFzM0cwNC9sbk5wSTdtYTRQb3QxYzZVQTNWWElDYmtSVmdTZTRJM2xO?=
 =?utf-8?B?eFlpUnM4UmIxZkIrL0pLZ0cxUEtnQlVJWGxWNG00RjkrUEU0YjJlMVdoU3Jq?=
 =?utf-8?B?MHFmQzVNTytoU0Y1YkxVQjNYdHhSWWhMRW9yOHRha0Y2Zmh6aTdvUW9EUy9o?=
 =?utf-8?B?dU1wZ2VsWHR1dktWVnJEYXI5azI1WmVWeDhqK1U4MWVraCs3ajVPRUdpcW5m?=
 =?utf-8?B?cWExYnJma2k4aHVHUEwzaWJiUmM0eGlIaWk5RVBQQkpaTFdZaThLelFtclpw?=
 =?utf-8?B?TmIvYzI4K3RGd3pnK2hpQ3R4aWVGWlNKVEZ0ZnFKSFdWTUx5a0FhblQ3bENv?=
 =?utf-8?B?MVhHZmowT29JQU5YekpkMk5aNEI4bnRzUFdjc2MyWlMyYk5iczRsd29FY0My?=
 =?utf-8?B?TjIzZCtTR2ZVNTRQaXpEMis2YU8xM2hwaklBTGN3ajMvektzWGVoQ3JDY3Rr?=
 =?utf-8?B?ZHRyS2Y0dlRnZjFQbHl1MFJxUm1JYXlHeE5yQStGd0h1bU1JcXB3U1FkZ3VU?=
 =?utf-8?B?ZmNXWmIwWnc4ZGpZMUFqYUFFQzVXTHN6VDJIWjVYOEQ2RHUxMW9VRVE5eVBI?=
 =?utf-8?B?N040M2Rwd3hUTmMzdHBtWTNrWWpROEt2ODd1RDNxWFpHWlpkRGZFK05ocW9D?=
 =?utf-8?B?bjE4V1c4eDg2cWhGYmhoMlBSY3pDZndhRzAxUWFBcFAvUFR2c3g0YzVuM0x0?=
 =?utf-8?B?ZHB4WktJcXZKOVlxUDlMOTVLYlZ1OHlZQ0hVZDdLS2czVnJENEEwZS90VFB4?=
 =?utf-8?B?VWhnRjhyTWUwcHlSTDQwTi95ZUpNOXo4ZWZCcEZySTEvNmhVazFiay9GdCti?=
 =?utf-8?B?MHlGTkpwUTcyMEhUYXVXMDIyYUI4NnVoeWk2UkY4L2crR3FBMWtoTXZEUWds?=
 =?utf-8?B?Sk8zRWI2cSt0OFdSck5kRlByWG55OWFaVjZMV3hDQUhVaFlzSmJtWEcvdWhL?=
 =?utf-8?B?NVBJdjFOYlZodjgwcDFvS1ZvakdoT1JOdk9FMlR3T0tWNHBlTWxnY1VHMDR1?=
 =?utf-8?B?bHlhTVdiOGhOcmEra0llMTVSRzhvVzhHQ0s4Ti9maHB6YnFjalBzVDJpY1Zv?=
 =?utf-8?B?WGhBM3RsSVFRT0JCUlQwc3VCQVNaTUNhY2w3Rmo5QTJHWS9Wa0pIUEphSXRu?=
 =?utf-8?B?SEN1K2pueE1IdlJHRTE3OVdSNU5EU1l3VFY5RE93M0M1eGJ6bENUd2t2MGpH?=
 =?utf-8?B?dXBhb0Q2c0h1MHJwN3BFWjRjZE5wU3dIbFQrNEhEaWlzMms5Q0JpKzBlYUM3?=
 =?utf-8?B?cG1PRnpyZnpoZTNJQ081SFQzT1g1QkNPVERydUZZY3JpcnhxWUYwTUJMVWNw?=
 =?utf-8?B?T2YzMlhjOVIyQ0hPVEI4MEx3eTBndTRKWXJlODNsNDNZcmZ6YktHQjVIam1k?=
 =?utf-8?Q?/qnSWHGfpw/FxX/wX+TZvt7La?=
X-MS-Exchange-CrossTenant-Network-Message-Id: b8869869-e2e8-489d-d670-08dc2d3a838b
X-MS-Exchange-CrossTenant-AuthSource: DS7PR11MB6269.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Feb 2024 08:54:11.9862
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 3WMdDbJYN1f47aOaZylQbzQjC4Fmg757Px5XonJjxsvIAVyjPn/BIadzJpqsOPoxHeTbtPFoAHZXqthQSX1Qaw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR11MB5817
X-OriginatorOrg: intel.com

On 2/13/2024 8:05 AM, James Bottomley wrote:
> On Mon, 2024-02-12 at 23:36 -0800, Xing, Cedric wrote:
>> On 2/9/2024 12:58 PM, Dan Williams wrote:
>>> James Bottomley wrote:
>>>> Just to correct this: IMA uses its own log format, but I think
>>>> this was a mistake long ago and the new log should use TCG2
>>>> format so all the tools know how to parse it.
>>>
>>> Is this a chance to nudge IMA towards a standard log format? In
>>> other words, one of the goals alongside userspace consumers of the
>>> RTMR log would be for IMA to support it as well as an alternate in-
>>> kernel backend next to TPM. IMA-over-TPM continues with its current
>>> format, IMA-over-RTMR internally unifies with the log format that
>>> is shared with RTMR-user-ABI.
>>>
>> I'm not a TCG expert. As far as I know,
>> https://trustedcomputinggroup.org/wp-content/uploads/TCG-PC-Client-Platform-Firmware-Profile-Version-1.06-Revision-52_pub-1.pdf
>>   
>> defines the event types for TCG2 logs for firmware uses only. I
>> cannot  find a spec that defines event types for OS or applications.
>> We may  reuse the firmware event types for Linux but I doubt they can
>> accommodate IMA.
> 
> The TCG crypto agile log format is
> 
>   index (32 bit),
>   event tag (32 bit),
>   digests array,
>   sized event entry (up to 4GB)
> 
> So an IMA log entry can definitely be transformed into this format
> (providing someone agrees to the tag or set of tags).  The slight
> problem would be that none of the current IMA tools would understand
> it, but that could be solved over time (the kernel could use the TCG
> format internally but transform to the IMA format for the current
> securityfs IMA log).
> 
Hi James,

As Mikko mentioned in his reply, TCG has defined the "Canonical Event 
Log Format" (aka. CEL) [1], while systemd-pcr* services use a subset of 
CEL format in their user space log.

I skimmed through the CEL spec today. Comparing to TCG2 log, CEL follows 
the same design (i.e., each event has a type field that determines the 
structure of the event data) but separates the encoding from the 
information model.

IMHO, CEL only works for applications defined in its information model 
(currently UEFI BIOS and IMA) but wouldn't work for any other 
applications like systemd. The systemd source code has documented the 
difference [2] between their log format and CEL.

One problem of CEL is its "content_type", which contains numeric values 
assigned by the spec. systemd doesn't have a numeric "content_type" 
assigned so has to use a string value - "systemd", which can only be 
encoded in JSON but not in TLV or CBOR. Technically, the systemd log is 
NOT CEL even though they claim that's a subset of it.

Another problem of CEL is that NOT every byte of an event is 
hashed/extended. CEL spec has defined for each "content_type" the subset 
of bytes to hash, so a verifier must understand ALL content types to be 
able to verify the integrity of a log. In other words, the integrity of 
a "systemd" log can never be verified by a CEL conformant verifier.

So I wouldn't recommend CEL to be the log format here.

We are looking for, as I believe, is a format that can accommodate all 
applications and allow application-agnostic verifiers. For every event, 
the kernel only needs to know what to store in the log, and what to 
hash/extend and to which measurement registers, but isn't concerned by 
the semantics of the event. If reusing CEL terms, what needs to be 
defined here is the "encoding" (so that every application can 
store/extend "something" in a log that every verifier knows how to 
replay); while every application should be allowed to define its own 
"information model".

-Cedric

[1] https://trustedcomputinggroup.org/resource/canonical-event-log-format/

[2] 
https://github.com/systemd/systemd/blob/e1390da0256bbe2017c4c2fbc636c54fe02c84cb/src/shared/tpm2-util.c#L6112

>> IMHO, we don't have to follow TCG2 format because TDX is never TPM,
>> nor are any other TEEs that support runtime measurements. The
>> existing TCG2 format looks to me somewhat like ASN.1 - well defined
>> but schema is needed to decode. In contrast, JSON is a lot more
>> popular than ASN.1  nowadays because it's human readable and doesn't
>> require a schema. I just wonder if we should introduce a text based
>> log format. We could make the log a text file, in which each line is
>> an event record and the digest of the line is extended to the
>> specified runtime measurement register. The content of each line
>> could be free-form at the ABI level, but we can still recommend a
>> convention for applications - e.g., the first word/column must be an
>> URL for readers to find out the format/syntax of the rest of the
>> line. Thoughts?
> 
> https://xkcd.com/927/
> 
That is funny :-D

I can't agree more, so "no log" I think is always an option.

>>   For the new TEE measurement log, I don't think it has to be
>> collocated with the BIOS log, because TEEs are never TPMs.
> 
> This depends.  Logs are separable by PCRs.  As in every entry for the
> same PCR could be in a separate, correctly ordered, log.  However, you
> can't have separate logs that both use the same PCR because they won't
> replay.
> 
We can have separate logs for the same PCR as long as there's a way to 
order those logs. A simple way is to record the current PCR value at the 
beginning of every log, then a verifier can always replay the log to get 
the PCR value at exit, and use that value to match the next log.

Anyway, those details are unimportant. What I intended to say was that 
those logs don't have to be in the same format.

> James
> 
> 
>