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

[Yeoreum Yun]

On Tue, Oct 20, 2026 at 01:47:55PM -0300, Jason Gunthorpe wrote:
> On Tue, Oct 20, 2026 at 04:18:45PM +0100, Yeoreum Yun wrote:
> > On Tue, Oct 20, 2026 at 11:58:06AM -0300, Jason Gunthorpe wrote:
> > > On Tue, Oct 20, 2026 at 03:43:47PM +0100, Yeoreum Yun wrote:
> > > > On Tue, Oct 20, 2026 at 11:36:20AM -0300, Jason Gunthorpe wrote:
> > > > > On Tue, Oct 20, 2026 at 03:13:19PM +0100, Yeoreum Yun wrote:
> > > > > > > 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).
> > > > > 
> > > > > I don't see that kind of complexity is necessary.. I think it is
> > > > > better to just have the root smcc bus spawn them 
> > > > > 
> > > > > > But, the *base* is common. and I couldn't find any proper location to
> > > > > > deploy *common* code unless making arm_firme.
> > > > > 
> > > > > What common code excatly?
> > > > > 
> > > > > There shouldn't be? Getting an attestation is entirely orthogonal to
> > > > > set link ide, for example?
> > > > > 
> > > > > If you can identify what you think would ever be common that might
> > > > > help clarifgy what to do..
> > > > 
> > > > I mean the BASE service of firme and typical example is shared buffer
> > > > allocation. I agree IDE and attestaion service are orthogonal. but
> > > > in case of base-service is not. it could be used for both service.
> > > 
> > > It doesn't look like it needs a "shared buffer", just allocate it
> > > right before invoking the SMC that needs the memory. Use a simple
> > > library function to help allocate it. No need for a struct device
> > > layer.
> > 
> > Retrieving a PAT requires a buffer shared between the worlds. Before
> > allocating that buffer, the driver needs to query its requirements
> > through the BASE service's feature-query calls.
> 
> So? Make the query, allocate the buffer, get the token, free
> it. Simple, one driver, no convoluted flows. Use a little library
> style call or inline to reduce duplication if eventually necessary.
> 
> > Considering possible extensions to the BASE service, my preference
> > would be to expose these operations through firme_device rather than
> > standalone library functions. The intention is to keep access to the
> > BASE service within FIRME-specific drivers and provide a consistent
> > interface for those drivers.
> 
> Try not to overdesign things. If we don't know we need it now based on
> how the current spec works don't imagine something else.
> 
> ARM spec design is informed by Linux implemetnation. Having a sane
> simple implemtnation in Linux will motivate future specs changes to
> align better.
> 
> > If we implments this with library, are you thinking that file should
> > be located at driver/firmware/arm_firme or other place? though we make it
> > with library, I still think it should be located at
> > driver/firmware/arm_firme or some place in arch/arm64, but as
> > perspective abstraction to mange firme helpers in one place,
> > I think this design seems good.
> 
> Will has indicated a preference for driver/firwmare

Okay. with this let me make a driver/firmware/arm_firme as library not
a module format and make this library APIs (base, attestation) to be used
attestation and other. This means device / driver registeration with
smccc and done in driver/attestation/provider but use the APIs from
/driver/firmware/arm_firme.

Thanks for clarification. let me post next RFCv2 after initial
attestation subsystem is settled in :)

-- 
Sincerely,
Yeoreum Yun