[PATCH v2 0/9] firmware: Add initial support for Arm FF-A

[Jens Wiklander]

Hi Sudeep,

On Tue, Nov 03, 2020 at 05:43:41PM +0000, Sudeep Holla wrote:
> Hi all,
> 
> Let me start stating this is just initial implementation to check on
> the idea of providing more in-kernel and userspace support. Lot of things
> are still work in progress, I am posting just to get the early feedback
> before building lot of things on this idea. Consider this more as RFC
> though not tagged explicity(just to avoid it being ignored :))
> 
> Arm Firmware Framework for Armv8-A specification[1] describes a software
> architecture that provides mechanism to utilise the virtualization
> extension to isolate software images and describes interfaces that
> standardize communication between the various software images. This
> includes communication between images in the Secure and Normal world.
> 
> The main idea here is to create FFA device to establish any communication
> with a partition(secure or normal world VM).
> 
> If it is a partition managed by hypervisor, then we will register chardev
> associated with each of those partition FFA device.
> 
> /dev/arm_ffa:
> 
> e3a48fa5-dc54-4a8b-898b-bdc4dfeeb7b8
> 49f65057-d002-4ae2-b4ee-d31c7940a13d
> 
> For in-kernel usage(mostly communication with secure partitions), only
> in-kernel APIs are accessible(no userspace). There may be a need to
> provide userspace access instead of in-kernel, it is not yet support
> in this series as we need way to identify those and I am not sure if
> that belong to DT.

With unfiltered VM to VM commnication from user space there's no easy
way for two VMs to exchange privileged information that excludes user
space. Perhaps access to the FFA device is considered privileged and
enough for all purposes.

If I've understood it correctly is VM to SP communication only allowed
via kernel mode in the VM. The communication with OP-TEE depends on this
with the recent commit c5b4312bea5d ("tee: optee: Add support for session
login client UUID generation").

Cheers,
Jens