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 10:50:06AM -0300, Jason Gunthorpe wrote:
> 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.

I think my explaination was poor. Apologise...
I'm not saying another bus making but just wrapper of smccc-bus APIs
for firme specific and definietly, this would separate the
multi-function SMC to defien each firme device (attestation and IDE).

But, the *base* is common. and I couldn't find any proper location to
deploy *common* code unless making arm_firme.

Also, this arm_firme  is useful to managing *firme* smc call
seperated only from the attestation stuff and this wouldn't be not
compliate since the /driver/attestation just call the driver register
and get the firme_device wrapping the smccc_device with proper
smc-callback for firme in its probe function.

> 
> > 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 :)
> 

Hopefully. and I'm seeing his branch and found a little bit fault.
I'll be back with some comments as soon as I check overall.


Thanks! ;)

-- 
Sincerely,
Yeoreum Yun