Re: [PATCH 0/2] Xen FF-A mediator

[Jens Wiklander <jens.wiklander@xxxxxxxxxx>]

On Wed, Jun 8, 2022 at 1:07 AM Stefano Stabellini
<sstabellini@xxxxxxxxxx> wrote:
>
> On Tue, 7 Jun 2022, Stefano Stabellini wrote:
> > On Tue, 7 Jun 2022, Jens Wiklander wrote:
> > > Hi,
> > >
> > > This patch sets add a FF-A [1] mediator modeled after the TEE mediator
> > > already present in Xen. The FF-A mediator implements the subset of the 
> > > FF-A
> > > 1.1 specification needed to communicate with OP-TEE using FF-A as 
> > > transport
> > > mechanism instead of SMC/HVC as with the TEE mediator. It allows a similar
> > > design in OP-TEE as with the TEE mediator where OP-TEE presents one 
> > > virtual
> > > partition of itself to each guest in Xen.
> > >
> > > The FF-A mediator is generic in the sense it has nothing OP-TEE specific
> > > except that only the subset needed for OP-TEE is implemented so far. The
> > > hooks needed to inform OP-TEE that a guest is created or destroyed is part
> > > of the FF-A specification.
> > >
> > > It should be possible to extend the FF-A mediator to implement a larger
> > > portion of the FF-A 1.1 specification without breaking with the way OP-TEE
> > > is communicated with here. So it should be possible to support any TEE or
> > > Secure Partition using FF-A as transport with this mediator.
> > >
> > > [1] https://developer.arm.com/documentation/den0077/latest
> > >
> > > Thanks,
> > > Jens
> >
> > Hi Jens,
> >
> > Many thanks for the patches! I tried to apply them to the master branch
> > but unfortunately they don't apply any longer. Could you please rebase
> > them on master (or even better rebase them on staging) and resend?
> >
> > Thank you!
>
> One question without having looked at the patches in details. These
> patches are necessary to mediate OS (e.g. Linux) interactions with
> OPTEE. The difference between xen/arch/arm/ffa.c and
> xen/arch/arm/tee/optee.c is the transport mechanism: shared mem vs. SMC.
> Is that right?
>
> If only the transport is different, would it make sense to place ffa.c
> under xen/arch/arm/tee?

FF-A is a standard Arm service with a different range of SMC Function
Identifiers. FF-A is used to communicate with SPs, Secure Partitions.
An SP can be a TEE but also something different.

There are similarities between xen/arch/arm/ffa.c and
xen/arch/arm/tee/optee.c, but I believe it's more in broader terms on
the surface.

FF-A is a generic transport protocol that is generic enough that Xen
doesn't even need to know anything about the entity it's facilitating
communication with except what's provided by FF-A. The idea is that
it's only the end points that need to be aware of details of the
protocol run on top of FF-A. This means that EL2 (Xen), EL3
(SPMD/TF-A) and S-EL2 (SPMC/Hafnium) in principle can be kept
unchanged and agnostic to Trusted OSes and what not.

>
> Without having looked at the details of the transport or the FF-A
> protocol let me ask you a question. Do you think it would be possible to
> share part of the implementation with xen/arch/arm/tee/optee.c? I am
> asking because intuitively, if only the transport is differenti I would
> have thought that some things could be common. But it doesn't look like
> the current patches are reusing anything from xen/arch/arm/tee/optee.c.
> Are the two protocols too different?

The two protocols are quite different. So far I haven't been able to
identify suitable common helper functions.

Thanks,
Jens