Re: [PATCH 0/3] arm64/virt: Add Arm CCA measurement register support

[Suzuki K Poulose]

Cc: Dan, Cedric, Dionna, Aneesh, Alexey. linux-coco

Hi Jason,

On 13/04/2026 13:59, Jason Gunthorpe wrote:
> On Mon, Apr 13, 2026 at 09:49:54AM +0100, Sami Mujawar wrote:
> > This series adds support for Arm Confidential Compute Architecture (CCA)
> > measurement registers in the Linux kernel, enabling guest Realms to
> > access, extend, and expose measurement values for attestation and runtime
> > integrity tracking.
> >
> > The Realm Management Monitor (RMM) defines a set of measurement registers
> > consisting of a Realm Initial Measurement (RIM) and a number of Realm
> > Extensible Measurements (REMs). This series introduces the necessary
> > infrastructure to interact with these registers via the RSI interface
> > and exposes them to userspace through the TSM measurement framework.
> >
> > At a high level, the series includes:
> >   - Helper interfaces for reading and extending measurement
> >     registers via RSI
> >   - Definitions for Realm hash algorithms as defined by the
> >     RMM specification
> >   - Integration with the TSM measurement subsystem and sysfs
> >     exposure for userspace visibility and interaction
> >
> > After applying this series, measurement registers are exposed under:
> >      /sys/devices/virtual/misc/arm_cca_guest/measurements/
>
> I'm surprised we get some random sysfs files? How does some more
> generic userspace figure out to use this vs a TPM or some other
> platform's version of it?

That is true. This is the infrastructure for exposing Runtime
Measurement registers (R/W) for use by the OS, complementing the
TSM_REPORTS (Read Only Platform measurements+Attestation Reports, e.g.
on CCA Attestation Report from RMM). Unlike the TSM reports,
this doesn't have a generic interface for userspace.


> I also think exposing PCRs as was done for TPM in sysfs was something
> of a mistake.. Allowing extension without logging is too low level and
> is very hard to build an entire attestation system around.
>
> I really think we are missing a subsystem here, TPM has sort of been
> filling this role in a non-generic way, but we should have a
> common uAPI for platform measurement & attestation:

Agreed, such a subsystem would solve the below.

>   - Discover available measurements
>   - Report signed measurements, with ingesting a nonce
>   - Report measurement logs
>   - Extend measurements and udpate logs
>   - Report certificates used in signing
>   - General reporting of various kinds of attestation evidence
>
> And it would be nice for the PCI devices and others to plug into the
> general framework as well instead of building a parallel TSM framework
> for handling evidence.

That makes sense and AFAIU, there are efforts in progress to expose
the Device measurements+Certificates in a different form. May be a good
idea to intervene early enough to see if we can find a common ground.

> Isn't this also sort of incomplete?  Doesn't anything serious need
> signed measurements? Isnt't there alot more data that comes out of RMM
> than just a few measurement registers?
As mentioned above, this series adds the support for Runtime Extendible
Measurements (REM in CCA, RTMR on TDX). The RIM+Platform Attestation is 
already provided via the TSM_REPORT


Kind regards
Suzuki

> Jason