Re: [PATCH 0/2] Xen FF-A mediator
On Wed, Jun 8, 2022 at 1:07 AM Stefano Stabellini 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
Re: [PATCH 0/2] Xen FF-A mediator
Hi Stefano, On Tue, Jun 7, 2022 at 11:55 PM 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? 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 >
Re: [PATCH 0/2] Xen FF-A mediator
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?
Re: [PATCH 0/2] Xen FF-A mediator
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
[PATCH 0/2] Xen FF-A mediator
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