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

[Sudeep Holla]

On Sat, Nov 28, 2020 at 01:25:02PM +0100, Jens Wiklander wrote:
> 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.

Though this usercase is dropped now, it was targeted for VMM and may be
it was not an issue there.

> Perhaps access to the FFA device is considered privileged and
> enough for all purposes.
>

I don't know TBH.

> If I've understood it correctly is VM to SP communication only allowed
> via kernel mode in the VM.

Correct.

> The communication with OP-TEE depends on this with the recent commit
> c5b4312bea5d ("tee: optee: Add support for session login client UUID
> generation").
>

OK, thanks for the info.

-- 
Regards,
Sudeep