Received-SPF: pass (google.com: domain of linux-kernel+bounces-63051-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Message-ID: <226df539-b3f4-4099-b6a6-293fa200c536@intel.com>
Date: Mon, 12 Feb 2024 23:36:27 -0800
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v2 0/4] tsm: Runtime measurement registers ABI
To: Dan Williams <dan.j.williams@intel.com>, James Bottomley
	<James.Bottomley@hansenpartnership.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>
Content-Language: en-US
From: "Xing, Cedric" <cedric.xing@intel.com>
In-Reply-To: <65c691e13a50d_afa42948a@dwillia2-xfh.jf.intel.com.notmuch>
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?cytzNWZod1JpNjZ2VFV6SGJ6ME9haHQxbHNnOThONElWb1g0Wk1aemMrUVhx?=
 =?utf-8?B?bVJHd1hrTTJHTlRVVkdMb3hTcTkzWStJTmRRZmMvTFRHMEllQ0hqVjBKaDFB?=
 =?utf-8?B?Y1dBd3JjazRYaWNENllIZGczbWhiWHlNYnhNWVFUajhXRXJKc3M4K2RseDFU?=
 =?utf-8?B?TTFOWXVwMFBCUjkxQ0lOY2dtU05aNE52WjBvQVZCbmxQb0RVRitacktiM2cr?=
 =?utf-8?B?ZkdZT3puQ2huWmRSTExWWUFVRTlGc3Yzai9sblBiN2RLSVcwK3cxZWhIYTI1?=
 =?utf-8?B?UUtsWjMzWmV6V0tBZmxKOE9sUDMzaGxHTm1RSXhaN0ZBNGozY3hnbVdnWHJ1?=
 =?utf-8?B?ZWRUWVFpVllHRWJKMWJPKzdMUW54MC9qSG1kU0pvS2czTC9KcU11NDMxM2Jr?=
 =?utf-8?B?ckFsYlpTSks3aDMvTWlMUSt0WkVKY0JpbGQ4MXhaaktLaldkeGhiNTFpNVZE?=
 =?utf-8?B?dGcxbUJ1dVQ3QzJhUWtVL00rbUZUZ2RIckJkQ2lRZG1zd1FGQVNYR1ZzQkt4?=
 =?utf-8?B?S2dPNUY4K056bXMyejFxNHBkMjBzYm52d2hGdlZ2TkxVQ1VMY0dDemtlNnhT?=
 =?utf-8?B?dWU5dlNXaXpRRkVoNzlUWUhzOXJqVjVFRWp0NThveHMycnZVMVh6T1Vsdm94?=
 =?utf-8?B?TzVxNHRLT2pNWDVmYzlCc2x3bEpKMFhWcTRaMXhYSms5cFl1T29VZ0tndzV6?=
 =?utf-8?B?V21qV2p2Y256TGxVNnQxMCsydURPd1RQTUFBRlVDM1NNNk9Wa045RHZGMHRq?=
 =?utf-8?B?TkZLak9hUENGZEhGZmNaR0F4SjRLY09mWVhzMDFDS1dCc21RdkN5S0w0dUwr?=
 =?utf-8?B?cTNXWHhESU9oQ1ozSXlJbUZ5NTA4dzUySUZKM1JwRS9WWFlHQ0U1djRCRkti?=
 =?utf-8?B?eG5BdlR2QWU4Z0c0T29na3YrbXYweWd2SlJDSVVHVHBCS3lIS0l3YmFhS3Az?=
 =?utf-8?B?WEhWSXNtemlodDdiTFhOS2RXZDNnUDAyQURiaXAxdzl5RG5KM1JaaFlnMk5l?=
 =?utf-8?B?YTRxZzcxdTNZa0prVjRuRURBSzdkRVpMUWpDWG9OekdoNno3LzhxbDR3QmxK?=
 =?utf-8?B?MWFLckthRFVHRDVWVUtGb3lBZUt4QURFTTd5OTlUTU1CMWtiak00bmNMS0Q0?=
 =?utf-8?B?WTQ3MVNhd1JiK1ZWb3IzdUlPcmRTYjJBL3hyaXdHdnkrSm81L2dTbjdxN3dV?=
 =?utf-8?B?S08rOFNpYms4UmVDV1IyWGcxV1JpOEtBS3YyQlRxMFpEakN1L1BIU1RXZzhm?=
 =?utf-8?B?MWd0dzRFVDVMRkNiSW50VU16b3dTRll2MHQxZlNZMXlWZG1kZmt5ZjRqNUto?=
 =?utf-8?B?Nkg5OEVQZDAzc1R4NElDMTlCdFVBMTRuWmtBVHMzL2FoUUo5VEpFRUVmYVU2?=
 =?utf-8?B?VkhMUjVTYVo0ZFhRMm1zK2U3cjg5RnRaaDZDQ2ZTeG16Ui9BM1VlaG44UE9q?=
 =?utf-8?B?SG4zMDhZbS9qbjA0QjRrR29aMDVrYk43QmxjekU1Vk51WDlOZ1kxeGdxSWdz?=
 =?utf-8?B?TC90WHVtTHh2bFhvZm5mbytEaGlyYTArei9UeGhKcXZJMmRVN1M4UXJMdEIv?=
 =?utf-8?B?alpsaW5LeG9GRnA0Z2gvLytJbUJyck0xUERXOHZBTVA5UWl6VTNTd1FncUYr?=
 =?utf-8?B?a01hQUNIWC9oN0tIS0hqcm5rUGhJUnQzODcrL0hLSGpXSUNyb1N2ZGVIbFkx?=
 =?utf-8?B?U2xwVk1tVVdnNDQ5a1JuM0JtWWR2WTZFeUhHWUlwZlIycmFJQlVLa0ZjZjBm?=
 =?utf-8?B?N0tmYjlOMzFKTFJiSE1LYTVUbmh2MEJML1RuLy9lRU4vWmpvUERSN2d3eWZ1?=
 =?utf-8?B?R1V5Z09weXpsUk9GWWFFSHprSlNzTytabHdXRnMwdStXYk5yUUZuc0t4VXl0?=
 =?utf-8?B?NTVGTUhlSTl1TitTQ2xWbHBIdWRGWVU5eFVENHFnb3p4TUNzMGliMDI5TU5u?=
 =?utf-8?B?cG0vbUpOQkloSE0rd3VNNlJqQkNSM1UvbzZtd2FuSGNVZHRVYXBTSkRyUS8x?=
 =?utf-8?B?ekpzVHdDZTFOaXhoQ1Y4ME53Q2l3bG9PQjc2bHVvekU0R0ozS2VRNFJBQzlX?=
 =?utf-8?B?THM4UnJHSWRJK2JlbHZwdW16MWRpNWlIaFprUnhtMlMzeWFkU2lwRTArM21v?=
 =?utf-8?Q?I22w9/I4a3LA+nm8piXe8HDeA?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 4aae3c99-2643-427b-cef7-08dc2c667f4a
X-MS-Exchange-CrossTenant-AuthSource: DS7PR11MB6269.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Feb 2024 07:36:31.5480
 (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: 5Fn9UQY+fUEhYtv9pa2t3baamWoM8Ry3RKhQ2o2oImCpQcYf/zJKMxoQGgcYoYtHV9dylGJnDkoB4vsvN5O+Xg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN9PR11MB5449
X-OriginatorOrg: intel.com

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.

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?

> ...but be warned the above is a comment from someone who knows nothing
> about IMA internals, just reacting to the comment.
> 
> 
>>> I am wondering where will the event log be stored? Is it in the
>>> log_area region of CCEL table?
>>
>> IMA stores its log in kernel memory and makes it visible in securityfs
>> (in the smae place as the measured boot log).  Since this interface is
>> using configfs, that's where I'd make the log visible.
>>
>> Just to add a note about how UEFI works: the measured boot log is
>> effectively copied into kernel memory because the UEFI memory it once
>> occupied is freed after exit boot services, so no UEFI interface will
>> suffice for the log location.
>>
>> I'd make the file exporting it root owned but probably readable by only
>> the people who can also extend it (presumably enforced by group?).
> 
> I assume EFI copying into kernel memory is ok because that log has a
> limited number of entries. If this RTMR log gets large I assume it needs
> some way cull entries that have been moved to storage. Maybe this is a
> problem IMA has already solved.

We don't have to, and are also not supposed to I guess, append to the 
log generated by BIOS. The kernel can start a new log, and potentially 
in a different format. I think the BIOS log is exposed via securityfs 
today. Am I correct? For the new TEE measurement log, I don't think it 
has to be collocated with the BIOS log, because TEEs are never TPMs.