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

Jens Wiklander (2):
  xen/arm: smccc: add support for SMCCCv1.2 extended input/output
    registers
  xen/arm: add FF-A mediator

 xen/arch/arm/Kconfig         |   11 +
 xen/arch/arm/Makefile        |    1 +
 xen/arch/arm/arm64/smc.S     |   43 +
 xen/arch/arm/domain.c        |   10 +
 xen/arch/arm/ffa.c           | 1624 ++++++++++++++++++++++++++++++++++
 xen/arch/arm/vsmc.c          |   19 +-
 xen/include/asm-arm/domain.h |    4 +
 xen/include/asm-arm/ffa.h    |   71 ++
 xen/include/asm-arm/smccc.h  |   42 +
 9 files changed, 1821 insertions(+), 4 deletions(-)
 create mode 100644 xen/arch/arm/ffa.c
 create mode 100644 xen/include/asm-arm/ffa.h

-- 
2.31.1

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!



> Jens Wiklander (2):
>   xen/arm: smccc: add support for SMCCCv1.2 extended input/output
>     registers
>   xen/arm: add FF-A mediator
> 
>  xen/arch/arm/Kconfig         |   11 +
>  xen/arch/arm/Makefile        |    1 +
>  xen/arch/arm/arm64/smc.S     |   43 +
>  xen/arch/arm/domain.c        |   10 +
>  xen/arch/arm/ffa.c           | 1624 ++++++++++++++++++++++++++++++++++
>  xen/arch/arm/vsmc.c          |   19 +-
>  xen/include/asm-arm/domain.h |    4 +
>  xen/include/asm-arm/ffa.h    |   71 ++
>  xen/include/asm-arm/smccc.h  |   42 +
>  9 files changed, 1821 insertions(+), 4 deletions(-)
>  create mode 100644 xen/arch/arm/ffa.c
>  create mode 100644 xen/include/asm-arm/ffa.h

Hi Stefano,

On Tue, Jun 7, 2022 at 11:55 PM Stefano Stabellini
<sstabellini@kernel.org> 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?

No problem, I'll rebase and send out a v2.

Thanks,
Jens

>
> Thank you!
>
>
>
> > Jens Wiklander (2):
> >   xen/arm: smccc: add support for SMCCCv1.2 extended input/output
> >     registers
> >   xen/arm: add FF-A mediator
> >
> >  xen/arch/arm/Kconfig         |   11 +
> >  xen/arch/arm/Makefile        |    1 +
> >  xen/arch/arm/arm64/smc.S     |   43 +
> >  xen/arch/arm/domain.c        |   10 +
> >  xen/arch/arm/ffa.c           | 1624 ++++++++++++++++++++++++++++++++++
> >  xen/arch/arm/vsmc.c          |   19 +-
> >  xen/include/asm-arm/domain.h |    4 +
> >  xen/include/asm-arm/ffa.h    |   71 ++
> >  xen/include/asm-arm/smccc.h  |   42 +
> >  9 files changed, 1821 insertions(+), 4 deletions(-)
> >  create mode 100644 xen/arch/arm/ffa.c
> >  create mode 100644 xen/include/asm-arm/ffa.h
>

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?

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?

On Wed, Jun 8, 2022 at 1:07 AM Stefano Stabellini
<sstabellini@kernel.org> 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