Re: [PATCH RFC 0/3] firmware: arm_firme: introduce FIRME support for host attestation

[Yeoreum Yun <yeoreum.yun@arm.com>]

On Mon, Oct 19, 2026 at 08:35:32PM -0300, Jason Gunthorpe wrote:
> On Mon, Oct 19, 2026 at 03:14:32PM +0100, Yeoreum Yun wrote:
> > The Arm Confidential Compute Architecture (CCA) introduces the
> > Realm Management Extension (FEAT_RME), which enables the creation and
> > management of dynamically allocated, attestable trusted execution
> > environments known as Realms.
> 
> Same remark as the other one, this is an attestation subsystem
> driver.. Stuff like this is *exactly* why we are building that.

Yes. I'm keeping in mind.

> 
> Also this is weirdly structured, it should just be one driver under
> drivers/attestation/ that does the measurement register part of firme,

JFYI, FIRME's platform attestation token doesn't have the measurement
register. ploatform attestation token will include the firmware
information (e.g. firmware hash) and verifier checks the firmware
information. the meaurement with RIM/REM will be part of Realm token.
FIRME's PAT is for host attestation and doesn't include Realm token.

Therefore, in the new UAPI, attestation only have the evidance
interface and MR interface wouldn't be used by making mr_cap as NULL.

> it shouldn't have two components and some weird firme_get_instance()
> thing to link them together. That isn't how to build HW drivers in
> Linux..
> 
> Since ARM has bundled different concepts together into one SMCC FID
> range, it probably make sense for the smccc_devices to somehow spawn
> multiple smccc_devices for the various internal software aspects
> rather than have one driver spawn aux devices to split it ..

If FIRME were intended solely for attestation, I think your suggestion
would make sense.

However, considering that FIRME may be extended to support other services,
such as IKE key management, I think having FIRME-related code scattered
across different subsystems would actually make things more complicated.

I initially considered introducing a dedicated FIRME bus as well,
but I felt that would be overengineering.

In my view, it would be better to manage the common FIRME functionality
within the FIRME layer (arm_firme), either through a single FIRME device
or by exposing multiple SMCCC devices for different services.

While both approaches are possible, I personally prefer the former, as it
keeps the FIRME-specific functionality together and provides a cleaner
structure. The individual service drivers could then be associated with
the FIRME device obtained via firme_get_instance() by setting dev.parent.

-- 
Sincerely,
Yeoreum Yun