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

["Xing, Cedric" <cedric.xing@intel.com>]

On 9/13/2024 7:55 AM, James Bottomley wrote:
> On Thu, 2024-09-12 at 14:00 -0500, Xing, Cedric wrote:
>> 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.
> 
> The IMA log has always been defined in
> 
> Documentation/security/IMA-templates
> 
> Even before CEL tried to add it as a format.
> 
We are on the same page. The TCG PC client profile spec didn't define 
IMA specific events. So IMA invented its own, and then was included into 
CEL.

>>   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.
> 
> I don't see how that would help:  From the IMA point of view there's no
> practical difference between extending a PCR and extending a RTMR (it's
> the same mathematical operation).  The difference is how you get the
> quote and verify the log matches it.
> 
> I do note that since the whole problem boils down to the different
> quoting mechanism between TPM and RTMR, it is entirely possible, since
> the Quoting Enclave is all in software, for them to produce a TPM quote
> even for RTMR measurements that could be verified against some external
> key.  That way all the IMA tools would just work for RTMRs (which would
> seem to me to be a much easier way of getting them to work with RTMRs).
> It's always baffled me why Intel is so adamant that every existing
> measurement tool and pathway should be rewritten for the RTMR approach
> instead of simply being compatible enough to get existing tools to work
> with RTMRs.  You can still keep the current RTMR quote format and the
> certificate chain, simply add the ability to produce a signature that
> matches the usual TPM quote.  Since a quote is only a signature over a
> public key, the tools would work and the only difference is how you
> confirm the certificate chain.
> 
There's significant difference in the trust model betweem TPM and CC 
TEEs. Specifically, in the TPM case the CRTM (usually the BIOS boot 
block) is simply trusted, while in the case of CC TEEs the CRTM (pretty 
much equivalent to the initial memory image) is measured. Additionally, 
TPM is soldered to a physical platform while TEEs can be migrated from 
platform to platform. Moreover, certain TEE implementations, like Intel 
TDX, rely on additional modules for security (e.g., TDX module, SEAM 
loader ACM, microcode), and some of those can be updated without 
rebooting (i.e., without tearing down TDs). Therefore, a "full" TD quote 
(which is still a work in progress) will have to convey more evidence 
than the current TPM quote format can possibly accommodate. That is, 
even if the Quoting Enclave (or Quoting TD in future) can sign a TPM 
quote (e.g., by striping off everything other than RTMRs), an 
attestation service would still have to verify/appraise other evidence 
conveyed outside of the TPM quote to establish trust in the TPM quote. I 
believe there are similar problems in other CC archs/implementations.

>> 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.
> 
> I think that's true, yes.  And that's precisely the problem with this
> proposal: you're completely pejorative about log format but know that
> no-one is going to change to the format you're trying to mandate.
> 
I'm not trying to mandate the format. I presented this option briefly to 
show that I had considered all possibilities. Also, see my response to 
your comment on the 3rd option below.

>> 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.
> 
> But this sounds even worse.  You're adding an extra layer and an extra
> logging tool simply to verify the PCR/RTMR quote and then after that
> you need to us IMA tools to verify the log.
> 
We are facing a challenge similar to what the TCP/IP stack solved many 
years ago. Think of it like this: the IMA log is the "application 
layer", where the actual data resides. The specific record syntax/format 
in the example (i.e., "ima_mr extend <hash_algo>/XYZ") acts like TCP, 
with `mr_ima` being a "TCP port". The rules introduced in this series 
for identifying event record boundaries and hashing, serve as the "link 
layer" to provide data integrity. The ultimate objective of this 
"layered measurement/attestation stack" is to allow multiple 
applications to share the same physical RTMR without interfering with 
each other.

Just as the TCP/IP stack requires different layers to handle various 
aspects of data communication, this approach do require additional 
tools, especially on the "attestation service" side. Given that we are 
just laying the groundwork, I believe the first option will have the 
least impact to existing s/w and will suffice for now.

-Cedric