Re: [PATCH v4 5/5] xen/arm: ffa: Enable VM to VM without firmware

[Bertrand Marquis <Bertrand.Marquis@xxxxxxx>]

Hi Julien,

> On 30 Mar 2025, at 23:38, Julien Grall <julien@xxxxxxx> wrote:
> 
> Hi Bertrand,
> 
> On 27/03/2025 08:37, Bertrand Marquis wrote:
>>> On 27 Mar 2025, at 00:41, Julien Grall <julien@xxxxxxx> 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
>