Message-ID: <c7157fb7-b8d0-482b-9ec3-d60179a95882@intel.com>
Date: Wed, 11 Sep 2024 22:23:48 -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

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.

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.

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.

-Cedric

On 9/11/2024 9:10 AM, James Bottomley wrote:
> On Wed, 2024-09-11 at 21:46 +0800, Qinkun Bao wrote:
>> On Wed, Sep 11, 2024 at 8:06 PM James Bottomley
>> <James.Bottomley@...senpartnership.com> wrote:
>>>
>>> On Tue, 2024-09-10 at 23:01 -0500, Xing, Cedric wrote:
>>>> On 9/10/2024 12:09 PM, Jean-Philippe Brucker wrote:
>>>>> Hi Cedric,
>>>>>
>>>>> On Sat, Sep 07, 2024 at 11:56:18PM -0500, Cedric Xing wrote:
>>>>>> Patch 2 introduces event log support for RTMRs, addressing
>>>>>> the fact that the standalone values of RTMRs, which represent
>>>>>> the cumulative digests of sequential events, are not fully
>>>>>> informative on their own.
>>>>>
>>>>> Would each event_log include the events that firmware wrote
>>>>> before Linux?
>>>>
>>>> No. The log format proposed here is textual and incompatible with
>>>> TCG2 log format.
>>>>
>>>> The proposed log format is based on the CoCo event log -
>>>> https://github.com/confidential-containers/guest-components/issues/495
>>>> .
>>>
>>> Given that AMD is planning to use the SVSM-vTPM for post launch
>>> measurements, not supporting TPMs in any form would make this Intel
>>> only on x86 and thus not very "unified".  Microsoft also tends to
>>> do attestations partly via the vTPM in its L1 openHCL component
>>> (even for TDX) and thus would also have difficulty adopting this
>>> proposal.
>>>
>>
>> Hi James,
>>
>> I don't think the patch should be blocked for not supporting the
>> SVSM-vTPM and it is not an Intel only patch.
> 
> Actually, I'm not objecting to the patch not supporting the TPM, I'm
> objecting to design choices, like the log, that make it much harder to
> add TPM support later.  Realistically if you want a universal
> measurement ABI, it has to work for physical systems as well, which
> means TPM or DICE, since RTMR is a bit non-standard.
> 
>> 1. Not everyone prefers the SVSM-vTPM as it lacks the persistent
>> storage and does not comply with TCG's TPM specifications. TPM is not
>> just about the measurement.
> 
> I think you'll find an ephemeral TPM is TCG compliant: the NV is
> actually an additional profile in the TCG specifications.
> 
>> Sealing and unsealing data is also a critical functionality for TPM.
>> Treating thenSVSM-vTPM as a TPM misleads users and disrupts existing
>> software based on TPMs. The SVSM-vTPM is not TPM. Just like
>> Javascript is not Java.
> 
> I've already explained several times how sealing and unsealing can be
> done with an ephemeral TPM. I'm not going to get into prejudices about
> naming.
> 
>> 2. If our goal is to measure the boot chain and post-launch, the RTMR
>> is an effective and straightforward method. We already support RTMR
>> for TDX. For SNP, simulating the RTMRs in SVSM is very simple while
>> implementing the SVSM-vTPM needs a lot of changes.
> 
> in the upstream, the vTPM is already done.  There's no current pull
> request for RTMR emulation.
> 
>> The SVSM-vTPM significantly expands the TCB while offering limited
>> security value enhancements compared to the RTMR.
> 
> So would every other feature on the coconut roadmap.
> 
>> 3. RTMR as a technology has been adopted widely. It is not an Intel
>> only technology. The TDX CVMs on Google Cloud already support RTMRs.
>> The TDX CVMs [1] on Alibaba Cloud supports RTMR as well. In terms of
>> the attestation verifiers, the token from Intel ITA [2] and Microsoft
>> Attestation Service [3] indicate they support RTMRs. The Ubuntu image
>> [4] from Canonical enables RTMR by default.
> 
> So you think Intel should abandon its work on ephemeral vTPMs for TDX?
> 
> Regards,
> 
> James
>   
> 

Powered by blists - more mailing lists