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

[Jason Gunthorpe <jgg@ziepe.ca>]

On Tue, Oct 20, 2026 at 02:41:48PM +0100, Yeoreum Yun wrote:
> > 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.

I wouldn't over complicated it. We already have smccc bus to do this,
we don't need layered stacks of busses here. Just change smccc bus to
be able to break up the multi-function SMC into several devices.

> 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

Lets give it a few weeks?

I'm confident both of your attestation drivers will go ahead at the
fastest possible speed once we get the subsystem settled :)

Jason