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

[Huang, Kai]

On Mon, 2025-03-17 at 17:49 -0500, Xing, Cedric wrote:
> 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 was thinking to put the reason(s) of choosing sysfs over configfs-tsm to the
changelog of this patch, as I had impression the ABI to expose MRs is also for
attestation or at least attestation related.

[...]

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

Ok as long as Dan is fine.

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

Thanks for the info.

Maybe it's also worth to put this into the changelog of this patch too, so that
readers can at least know why we didn't choose to unify the ABI.

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

I think we can also parse the quote from the configfs-tsm if apps want, or we
can also introduce new configfs-tsm attributes for individual MRs if needed. 
But I think the key reason we choose sysfs for MRs is they are platform global
while configfs-tsm fits per-application more.

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

I think another concern is the Quote format may not be stable (e.g., for those
signed by different QEs), i.e., the location of the TDREPORT in the Quote may be
different.  Right?

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

I wish we can have a more common name rather than "Measurement Registers", but
we are already here. :-)

> They are needed by applications 
> for verifying, for example, security policies that must be enforced. 
> 

I appreciate if youy could elaborate a little bit?  E.g., reading MRCNOFIGID
could be used for enforcing what kinda security policy?

> Do 
> you see the need for reading them now?

No.

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

Yeah thanks for the explanation.  As long as Dan is fine with this "bottom
layer" all good :-)

Thanks again for the detailed reply!