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

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

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

Yeap. but current, it's enough with evidance.

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

Then, I think the arm_firme layer could simply wrap smccc_driver and
smccc_device, with an extensible base interface shared across services.

In other words, the attestation layer (driver/attestation) would register
a firme_driver via wrapper provided in arm_firme layer that binds to the
corresponding attestation firme_device without implementing firme bus type
(of course, the smccc devices are delcared according to service in
smccc-bus layer).

This would eliminate the need for firme_get_instance(). Instead,
the attestation layer would obtain the FIRME attestation device and
use its function pointers to access FIRME’s attestation and base services
provided from arm_firme layer.

Would it be better to post based on Jiri's branch [0] for next-spin?

Thanks for your comments! :)

Link: [0] https://github.com/jpirko/linux_mlxsw/tree/wip_attestation_pre_rfc_draft1

-- 
Sincerely,
Yeoreum Yun