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:

quoted

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel