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

[Jason Gunthorpe]

On Tue, Oct 20, 2026 at 08:13:37AM +0100, Yeoreum Yun wrote:

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

I'm aware, and this may change.

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

The FID are largely orthogonal, AFAICT there is no shared
infrastructure between the various functional blocks.

SO it needs to be split into proper narrow drives in the eventual
kernel implementation. token goes to attestation, link ide goes to
tsm, and so on.

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

Nope, it is the right thing to do from a kernel perspective. We always
de-agregate these kinds of multi-function devices into proper
per-subsystem driver.s
 
> I initially considered introducing a dedicated FIRME bus as well,
> but I felt that would be overengineering.

Nope, just use the smccc bus and split up the 'multi-function FID'
there. It doesn't need to be over complicated.

Jason