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
