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

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Thu, 2024-09-12 at 14:00 -0500, Xing, Cedric wrote:
> On 9/12/2024 7:15 AM, James Bottomley wrote:
> > On Wed, 2024-09-11 at 22:23 -0500, Xing, Cedric wrote:
> > > 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.
> > 
> > Well, the PCRs are already exposed through
> > 
> TPM predates TSM so has an existing implementation for sure.
> 
> > /sys/class/tpm/tpm0/pcr-<algo>/<n>
> > 
> > but they don't have much meaning without the log.
> > 
> Consolidating PCRs under TSM is not a requirement.

As I keep saying I'm not expecting you to do it.  However, it will be a
requirement for consolidating AMD SNP under this using the SVSM-vTPM,
so I do expect someone will do it.

>  But if it's desirable, it could be done. When it comes to the log,
> the assumption here is that we will switch log format after TSM takes
> over. The preboot log can stay where it is today. Yeah, it would be
> kinda ugly without a  unified log, but the separation of
> semantics/storage is more important,  because otherwise it will be
> very difficult to enable new applications.

I really don't think you'd want to do that because it creates a bigger
mess for all the tools if you keep using the same PCRs because now they
have to know where the log switches and how to change the extensions. 
There's no tool today that can do this.


> > > 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.
> > 
> > And the IMA log, which is runtime and isn't TCG2?
> > 
> 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.

>  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.

> 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.

> 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.

James