public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@ziepe.ca>
To: Sami Mujawar <sami.mujawar@arm.com>, Dan Williams <djbw@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, catalin.marinas@arm.com,
	will@kernel.org, thuth@redhat.com, Suzuki.Poulose@arm.com,
	steven.price@arm.com, gshan@redhat.com, YeoReum.Yun@arm.com
Subject: Re: [PATCH 0/3] arm64/virt: Add Arm CCA measurement register support
Date: Mon, 13 Apr 2026 09:59:25 -0300	[thread overview]
Message-ID: <20260413125925.GK3694781@ziepe.ca> (raw)
In-Reply-To: <20260413084957.327661-1-sami.mujawar@arm.com>

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


  parent reply	other threads:[~2026-04-13 12:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-13  8:49 [PATCH 0/3] arm64/virt: Add Arm CCA measurement register support Sami Mujawar
2026-04-13  8:49 ` [PATCH 1/3] arm64: rsi: Add helpers for Arm CCA measurement register operations Sami Mujawar
2026-04-13  8:49 ` [PATCH 2/3] arm64: rsi: Add realm hash algorithm defines Sami Mujawar
2026-04-13  8:49 ` [PATCH 3/3] virt: arm-cca-guest: Add support for measurement registers Sami Mujawar
2026-04-13 12:59 ` Jason Gunthorpe [this message]
2026-04-14 10:10   ` [PATCH 0/3] arm64/virt: Add Arm CCA measurement register support Suzuki K Poulose
2026-04-14 12:29     ` Jason Gunthorpe
2026-04-14 13:26       ` Suzuki K Poulose
2026-04-14 13:35         ` Jason Gunthorpe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260413125925.GK3694781@ziepe.ca \
    --to=jgg@ziepe.ca \
    --cc=Suzuki.Poulose@arm.com \
    --cc=YeoReum.Yun@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=djbw@kernel.org \
    --cc=gshan@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sami.mujawar@arm.com \
    --cc=steven.price@arm.com \
    --cc=thuth@redhat.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox