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/

  Where:
   - rim is read-only (initial measurement)
   - rem[0-3] are read/write (extensible measurements)
   - The hash algorithm reflects the Realm configuration

Patch summary:
 1. arm64: rsi: Add helpers for Arm CCA measurement registers
   - Introduces RSI helper APIs to read and extend RIM/REM registers

 2. arm64: rsi: Add realm hash algorithm defines
   - Adds definitions for SHA-256 and SHA-512 identifiers returned
     by the RMM

 3. virt: arm-cca-guest: Add support for measurement registers
   - Integrates with TSM measurement framework
   - Implements measurement register refresh and extend operations
   - Exposes registers via sysfs using a misc device
   - Dynamically configures hash algorithm and digest size per Realm

This enables a consistent mechanism for attestation-related measurements
in Arm CCA guests and aligns with the kernel TSM measurement abstraction.

Feedback is very welcome.

Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>

Sami Mujawar (3):
  arm64: rsi: Add helpers for Arm CCA measurement register operations
  arm64: rsi: Add realm hash algorithm defines
  virt: arm-cca-guest: Add support for measurement registers

 .../sysfs-devices-virtual-misc-arm_cca_guest  |  38 +++
 arch/arm64/include/asm/rsi_cmds.h             | 105 ++++++-
 arch/arm64/include/asm/rsi_smc.h              |   7 +
 drivers/virt/coco/arm-cca-guest/Kconfig       |   1 +
 .../virt/coco/arm-cca-guest/arm-cca-guest.c   | 296 +++++++++++++++++-
 5 files changed, 442 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-devices-virtual-misc-arm_cca_guest

-- 
SAMI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}

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?

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

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?

Jason

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

On Tue, Apr 14, 2026 at 11:10:51AM +0100, Suzuki K Poulose wrote:

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

Okay, but what actual use is this?

Extendable measrements with no log
Measurement read back without signature

What is the use case? What do you imagine any userspace will do with
this? Put it in the cover letter.

I don't think the raw rmm calls are sufficiently developed to be
usable directly by userspace. They are less capable than TPM and even
TPM has a lot of software around it to make it useful.

Jason

On 14/04/2026 13:29, Jason Gunthorpe wrote:
> On Tue, Apr 14, 2026 at 11:10:51AM +0100, Suzuki K Poulose wrote:
> 
>>> 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
> 
> Okay, but what actual use is this?
> 

Good point. This REMs are planned to be used for 
EFI_CC_MEASUREMENT_PROTOCOL as described below:

https://github.com/tianocore/edk2/issues/11383

At the moment they are exposed as raw, similar to the Intel TDX RTMRs.
This may eventually need to be connected to IMA subsystem.

> Extendable measrements with no log
> Measurement read back without signature
> 
> What is the use case? What do you imagine any userspace will do with
> this? Put it in the cover letter.

Agreed.

> 
> I don't think the raw rmm calls are sufficiently developed to be
> usable directly by userspace. They are less capable than TPM and even
> TPM has a lot of software around it to make it useful.

See above.

Kind regards
Suzuki

> 
> Jason

On Tue, Apr 14, 2026 at 02:26:58PM +0100, Suzuki K Poulose wrote:
> On 14/04/2026 13:29, Jason Gunthorpe wrote:
> > On Tue, Apr 14, 2026 at 11:10:51AM +0100, Suzuki K Poulose wrote:
> > 
> > > > 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
> > 
> > Okay, but what actual use is this?
> > 
> 
> Good point. This REMs are planned to be used for EFI_CC_MEASUREMENT_PROTOCOL
> as described below:
> 
> https://github.com/tianocore/edk2/issues/11383

So this is tying it to the same FW event log that TPM uses.

I think that strengthens my point this should all be uninform. TPM
drivers are directly exposing the event log today, but I guess that
needs generalization if non-TPM drivers are going to present it as
well.

How do you imagine getting and manipulating the EFI event log to use
with this?

Jason