Hi Julien, > On 30 Mar 2025, at 23:38, Julien Grall <jul...@xen.org> wrote: > > Hi Bertrand, > > On 27/03/2025 08:37, Bertrand Marquis wrote: >>> On 27 Mar 2025, at 00:41, Julien Grall <jul...@xen.org> wrote: >>> >>> Hi Bertrand, >>> >>> On 24/03/2025 13:53, Bertrand Marquis wrote: >>>> When VM to VM support is activated and there is no suitable FF-A support >>>> in the firmware, enable FF-A support for VMs to allow using it for VM to >>>> VM communications. >>> >>> tee/ and the callbacks associated are meant to be used for mediatiors. My >>> current interpretation ist this is only meant to interpose between a guest >>> and physical resources. Here you are extending the meaning to "virtual >>> TEE". I am sort of ok with that but ... >> I see what you mean but FF-A will not only be used to communicate with TEE >> (even if the primary use case right now is this one, including have it in a >> VM instead of the secure world). > > >> >>>> If there is OP-TEE running in the secure world and using the non FF-A >>>> communication system, having CONFIG_FFA_VM_TO_VM could be non functional >>>> (if optee is probed first) or OP-TEE could be non functional (if FF-A is >>>> probed first) so it is not recommended to activate the configuration >>>> option for such systems. >>> >>> ... this part is concerning me. You should be able to build with >>> CONFIG_FFA_VM_TO_VM and still boot when OP-TEE is present on the system. >>> This is not too critical now as this is tech preview but this is definitely >>> a blocker for making FFA supported. Can this be mentioned at the top of the >>> ffa.c file (which already contains existing blocker)? >> OP-TEE supports FF-A and in fact should be switched to using it by default >> as it allows it to run in parallel of other TEEs in the secure world or have >> FF-A compliant SPs running on top of OP-TEE. >> More and more you will see FF-A popping up as a recommended (or required) >> part of the firmware features. >> So the only reason to use OP-TEE without FF-A is if you have an old OP-TEE >> in which case your firmware will not support FF-A and using it between VMs >> is probably not required. > > Thanks for the clarification. I know we only support OP-TEE in Xen today, but > do you know what will happen for the other TEEs? Will they adopt FF-A?
On Arm the idea is to make them adopt FF-A yes and it will be part of System Ready recommendations in the future. > >>> >>> Also, given this would expose a fully virtual TEE, we should be able to >>> have a system where you have some VMs talking FFA and some using the >>> physical OPTEE (or another TEE). Whether we want to support it is a >>> different question but this design would prevent it. Is this intended? >> Right now i would say this is definitely not something we need as part of >> the tech preview as anybody using this feature in Xen would use an OP-TEE >> with FF-A support. >> But from Xen point of view, we should (if we can) support running on old >> systems with an existing OP-TEE but still use FF-A between VMs. >> This has some consequences on how the tee mediator and FF-A support is >> designed and I will definitely give it some thoughts (primary idea would be >> to decouple FF-A with secure as mediator to FF-A between VMs somehow). > > I am not sure we need to decouple anything. Today, we can already specify the > type of the TEE used by a given VM (see tee_type). But we are enforcing the > TEE type match the one of the current mediator. Yes for VMs this has to be specified explicitly, this was the idea behind the command line parameter for Xen to. > > So what if we allow multiple mediator to run and when the domain is > initialized we select the correct medatior/ops for the VM? Right now a VM gets the mediator selected by configuration if it is available. I do not think we should make it automatic as there might be good reasons to not allow to access a TEE from some VMs. > > For simplification, we could even hardocode FF-A as the second mediator. That could be a long term solution yes but we definitely need to solve the access rights first. As long as VMs can use FF-A to communicate with any other VMs or TEEs, the current approach is the most secure one. > >> For the review side of things, am I right to understand from your comments >> that this ok for now as tech-preview ? > > Yes I am happy with the approach for now. Great thanks. Cheers Bertrand > > Cheers, > > -- > Julien Grall >
