Re: [PATCH v2 1/4] tsm: Add TVM Measurement Register support

[Xing, Cedric]

On 3/12/2025 6:11 PM, Huang, Kai wrote:
[...]	
> > The key difference between MRs and reports/quotes is the lack of
> > context. Reports/quotes benefit from having a separate context for each
> > container, ensuring they don't interfere with each other. However, MRs
> > are global, and creating separate contexts would be confusing since
> > changes/extensions to MRs by one container will always be visible to others.
>
> This makes sense.  Could you put those into the changelog?
MRs have been under sysfs since the first version of the RFC patch. I'm 
not sure which changelog to put it in.

> I still have a slight concern (more like a question) though:
>
>  From attestation's point of view, ultimately, those MRs serves the same purpose
> as the static ones -- to be included in a verifiable attestation report to
> provide trustiness.  I think in most use cases the runtime MRs will be just
> extended once at early stage, e.g., during system boots (since they are global
> as you mentioned above).  And after that, they will just be read by applications
> (e.g., containers).
There are applications that require reading/extending RTMRs way past 
boot. For example, a container runtime may extend the path of the 
executable started inside an existing container, the container can then 
read the RTMR back to determine if there have been additional processes 
started by the user since its entrypoint.

> So the question is whether do we see any requirement for containers to *read*
> those MRs independently w/o the full report? From attestation's point of view, I
> don't think there is, because those MRs alone are not verifiable.  But I am not
> sure in your mind whether there's other use cases in which providing MRs for
> read in configfs-tsm would be helpful?
MRs, when read inside the guest, are considered trusted, as the guest 
trusts both the attestation environment (e.g., the TDX module) and the 
underlying communication channel. And there are applications like the 
example above that read RTMRs inside the guest. Please also note that 
reading MRs are very useful in debugging/diagnoses too. Just like 
"tainted kernel" messages, they aren't necessary but are very helpful. 
As another reference, TPM also provides TPM_PCR_Read command.

> > Below is TDX specific:
> >
> > Report0/reportdata is an exception, as report0 serves as a comprehensive
> > list of all measurements rather than a container-specific report.
> > reportdata provides an easy way to request a report if inter-container
> > race isn't a concern for your application.
> >
> > I can see the confusion here though (both Mikko and you raised the same
> > concern). I can (1) take away reportdata but leave report0 as it;
>
> I don't quite follow what's the value of leaving report0 w/o reportdata.
The intention is to allow access to _all_ measurements of a TD. There 
are measurement items not exposed to sysfs, such as MRSIGNERSEAM, 
CPUSVN, etc. They are not exposed individually because their uses are 
really rare/limited. Leaving a report0 here will allow users to examine 
their values when needed. REPORTDATA will be hard-coded to 0.

In other words, report0 here serves as a "container" for all TD 
measurements. It isn't meant to be used in local attestation. Its name 
"report0" merely suggests the its format follows the TDREPORT v0 
definition in the SDM (so people know how to interpret it).

> > or (2)
> > take away reportdata and break down report0 into tee_tcb_info and tdinfo
> > (and strip off report_mac_struct) so user can still have a comprehensive
> > list of MRs;
>
> Ditto. W/o reportdata, what value are you going to fill into the report0?
>
> I think the confusion is _why_ do you want to provide the full report0 via
> sysfs?  Is it for local verification, presumably?  In which case, probably you
> don't need to care about the reportdata?
>
> I can understand the purpose of exporting runtime MRs, I can even understand
> (sort of) the purpose of exporting other files like 'mrowner' etc, but I am not
> sure the purpose of exporting report0.
I can see the confusion from your comments. Guess neither (1) nor (2) is 
a good option.

> > or (3) take away report0/reportdata altogether. Which one
> > do you think is the most reasonable?
>
> 3) Seems more reasonable to me, but I am not certain because I don't fully
> understand the purpose (use case).
>
> > In all cases, I'll incorporate
> > Mikko's patch into this series to allow per-container TDREPORT under
> > configfs.
>
> Sorry I might have missed, where can I find this patch?
Mikko's patch is at 
https://gist.github.com/mythi/1c54fdb143c961146453261c725cd485

I'll incorporate it into the next revision.

[...]
> I think it is still valid question that whether we need to make those MRs
> consistent for all vendors for the purpose of providing a unified ABI to
> userspace.
>
> IIUC, Dan has been wanting unified ABIs around attestation.  It would be great
> if Dan can provide guidance here.
Yes, Dan and I had discussed this long ago. Just a bit clarification 
here, this ABI is mainly measurement but not for attestation.

Given the lack of unified HW from different vendors, there cannot be a 
low level unified ABI. A higher level ABI (with HW specifics abstracted 
away) was once proposed - i.e., the log oriented ABI. But it turned out 
difficult to agree upon a log format. Anyway, the abstraction doesn't 
have to be done in kernel mode, as long as MRs are made accessible to 
user mode. This patch is laying the groundwork for that.

[...]
> > > Please correct me if I am wrong: in my understanding, the purpose is to provide
> > > a "unified ABI for usrspace" for MRs, but not just some common infrastructure in
> > > the kernel to support exposing MRs, right?
> > >
> > > Configfs-tsm provides consistent names for all attributes for all vendors:
> > > 'inblob', 'outblob', 'generation', 'provider' etc, so it provides a unified ABI
> > > for userspace.
> > "attestation reports" in this configfs context refers to opaque blobs
> > consumed by external parties, while the guest acts as the "wire" for
> > transporting the reports.
>
> I interpret this as there's no requirement for containers to *read* those MRs
> independently via configfs-tsm. :-)
Yes and no. Containers have the need to read MRs, but doesn't have (the 
need) to verify them (and the credentials backing them). It is a 
separate question whether to read MRs via sysfs or configfs. The 
structure of configfs-tsm is optimized for usages that doesn't require 
parsing/interpreting the quotes from within the guest, while The 
structure of sysfs-tsm is optimized for the opposite.

Please note that, at least in the case of TDX, quotes have a lot bigger 
TCB than TDREPORTs, so shouldn't be used unless TDREPORTs cannot serve 
the same purpose.

> > > But here actually each vendor will have its own directory.  E.g., for TDX we
> > > have:
> > >
> > > 	/sys/kernel/tsm/tdx/...
> > >
> > > And the actual MRs under the vendor-specific directory are completely vendor-
> > > specific.  E.g., as shown in the last patch, for TDX we have: mrconfigid,
> > > mrowner etc.  And for other vendors they are free to register MRs on their own.
> > In contrast, MRs (especially extensible/RT MRs) are consumed by the
> > guest itself.
>
> Yeah agreed.  But eventually they are for attestation, right?
No. From the perspective of this ABI, MRs are "mainly" for measurement. 
By "mainly", I mean there are MRs like MRCONFIGID on TDX and HOSTDATA on 
SEV, that are simply immutable storage. They are needed by applications 
for verifying, for example, security policies that must be enforced. Do 
you see the need for reading them now?

> > They are vendor specific because they are _indeed_ vendor
> > specific. The intention is to unlock access to all of them for user
> > mode.
>
> Agreed.
>
> > The semantics (i.e., which MR stores what measurement) is
> > application specific and will be assigned by the application.
>
> This doesn't mean the kernel shouldn't provide a unified ABI to userspace
> AFAICT.
A log oriented ABI was once proposed, but we failed to reach an 
agreement on the log format. Moreover, this may be a problem better 
solved in user space.

> > > Could you elaborate how userspace is supposed to use those MRs in a common way?
> > >    
> > > Or this is not the purpose?
> > Sure. For example, CoCo may require storing container measurements into
> > an RTMR. Then, a potential implementation could extend those
> > measurements to an "RTMR file" named "container_mr", which could be a
> > symlink pointing to different RTMRs on different archs.
>
> OK.
>
> > Of course, we are hand-waiving the potential difference in the
> > number/naming of the MRs and the hash algorithms they use in the example
> > above.
>
> I think the number is fine.  E.g., in the above case, the application could have
> a policy to map a given container measurement to one RTMR (e.g., container0 ->
> rtmr0 and so on).
>
> And I am not sure why hash algorithm matters?  If needed, there could be a
> policy to query the hash algorithm for a given RTMR and feed extended data based
> on the algo in each loop.
The existence of a "mapping policy" implies the application is aware of 
the underlying HW, meaning the application cannot work on new HW 
released after the application.

"Querying hash algorithm" will work only if the application is aware 
(and carries the implementation) of the hash. This was how crypto 
agility got introduced into TPM2.0, as old applications can't understand 
new hash algos.

IMHO, what's really required by applications/attesters is the ability to 
log "events" (e.g., a container signed by a specific authority has been 
loaded/started), while what's required by verifiers/appraisers is the 
ability to verify those "events". Neither party has the need to 
understand the HW specifics (number/names of MRs and hash algos). 
Therefore, an ideal solution should be log oriented: Applications append 
"events" to logs while verifiers extract "events" from logs, with the HW 
specifics encapsulated in a separate "bottom layer". This ABI is part of 
that "bottom layer", upon which the rest of the stack can be built out 
in user space.

> > Generally, as shown in the example above, common names (e.g.,
> > "container_mr") don't provide common semantics (e.g., different hash, or
> > different measurements may be extended to the same or different MRs on
> > different archs), so we avoid using them. A full solution would require
> > a log-oriented ABI and a virtual measurement stack. We're laying the
> > groundwork for this today.
>
> As above, I don't think I am convinced that a unified ABI doesn't work, or isn't
> necessary.
Please see above.

> Again, no blocker from me, but I am hoping Dan can provide guidance here.
[...]

-Cedric