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

From: Xing, Cedric
Date: Sun Sep 15 2024 - 00:32:29 EST

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