[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 0/2] Xen FF-A mediator
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |