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

[Dionna Amalie Glaze]

On Wed, Mar 19, 2025 at 4:29 AM Huang, Kai <kai.huang@xxxxxxxxx> wrote:
>
> 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. :-)

The IETF RATS working group has proposed a general measurement type of
"integrity registers" in the CoRIM draft spec to accommodate PCRs and
RTMRs.
/shrug

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


-- 
-Dionna Glaze, PhD, CISSP, CCSP (she/her)