Re: [PATCH] tee: Add Arm FF-A TEE driver
From: Sumit Garg
Date: Wed Apr 27 2022 - 09:36:21 EST
On Tue, 26 Apr 2022 at 20:15, Sudeep Holla <sudeep.holla@xxxxxxx> wrote:
> On Fri, Apr 22, 2022 at 12:29:26PM +0530, Sumit Garg wrote:
> > Hi Sudeep,
> > On Fri, 8 Apr 2022 at 19:11, Sudeep Holla <sudeep.holla@xxxxxxx> wrote:
> > >
> > > The Arm FF-A provides mechanism for Linux kernel and modules to
> > > communicate with the secure partitions. This is useful for some
> > > Trusted-OS driver that are kernel resident or modules.
> > >
> > > We would also like to avoid adding kernel drivers to communicate with
> > > each and every service provided by these secure partitions. In order to
> > > achieve the same with FF-A, it would be better to provide user-space
> > > interface to access the FF-A functionalities. TEE subsystem seems to be
> > > the best suited to meet those requirements without having to create a
> > > new solution custom to FF-A alone.
> > Yeah, this interface sounds interesting.
> Good to hear that.
> > >
> > > All FF-A partitions that user-space access can be associated with this
> > > new FF-A TEE driver and represented by a single TEE device. Though the
> > > various secure services are generally distributed across multiple secure
> > > partitions, all of these can be made accessible through this single FF-A
> > > TEE device.
> > >
> > > The minimal functionality needed by the user space application is
> > > implemented, namely:
> > > - Query all partition IDs for a specific FF-A UUID
> > > - Sending synchronous message to a partition
> > > - Share/unshare buffer with the partition
> > >
> > Are there any corresponding user-space applications/libraries
> > available to get hands-on with this interface?
> Not sure if the changes to make use of this new interface is publicly
> available yet as these APIs are subject to change. I will see if something
> can be shared, but this is the project I am using to test with relevant
> changes to use these TEE APIs.
AFAIR, there is a concept of trusted services being launched by OP-TEE
as well . Is it the environment you are testing this interface
> > > Cc: Jens Wiklander <jens.wiklander@xxxxxxxxxx>
> > > Cc: Sumit Garg <sumit.garg@xxxxxxxxxx>
> > > Co-developed-by: Balint Dobszay <balint.dobszay@xxxxxxx>
> > > Signed-off-by: Balint Dobszay <balint.dobszay@xxxxxxx>
> > > Signed-off-by: Sudeep Holla <sudeep.holla@xxxxxxx>
> > > ---
> > > drivers/tee/Kconfig | 1 +
> > > drivers/tee/Makefile | 1 +
> > > drivers/tee/arm_ffa_tee/Kconfig | 15 +
> > > drivers/tee/arm_ffa_tee/Makefile | 6 +
> > > drivers/tee/arm_ffa_tee/core.c | 460 ++++++++++++++++++++++
> > > drivers/tee/arm_ffa_tee/ffa_tee_private.h | 39 ++
> > > drivers/tee/arm_ffa_tee/shm_pool.c | 94 +++++
> > > drivers/tee/arm_ffa_tee/ts_msg.c | 133 +++++++
> > > drivers/tee/arm_ffa_tee/ts_msg.h | 75 ++++
> > > include/uapi/linux/arm_ffa_tee.h | 116 ++++++
> > > include/uapi/linux/tee.h | 1 +
> > > 11 files changed, 941 insertions(+)
> > > create mode 100644 drivers/tee/arm_ffa_tee/Kconfig
> > > create mode 100644 drivers/tee/arm_ffa_tee/Makefile
> > > create mode 100644 drivers/tee/arm_ffa_tee/core.c
> > > create mode 100644 drivers/tee/arm_ffa_tee/ffa_tee_private.h
> > > create mode 100644 drivers/tee/arm_ffa_tee/shm_pool.c
> > > create mode 100644 drivers/tee/arm_ffa_tee/ts_msg.c
> > > create mode 100644 drivers/tee/arm_ffa_tee/ts_msg.h
> > > create mode 100644 include/uapi/linux/arm_ffa_tee.h
> > >
> > > Hi All,
> > >
> > > This is the initial version of FF-A TEE driver to get the feedback on the
> > > overall design/approach.
> > >
> > > Few TODOs I plan to do before we finalise:
> > > 1. Need to decouple the driver from few Trusted Service protocols currently
> > > implemented. I have WIP, but couldn't get all the tests working(yet to
> > > figure out whether the issue is in driver or tests themselves). Just
> > > posting it as is to get initial feedback on other areas.
> > Yes I would be in favor of this.
> I am too, but Balint had some concerns which I need to discuss with him yet.
> > >
> > > 2. Based on the way FF-A spec changes/discussions, does it make sense to
> > > make search based on UUID + partitionID instead of just partitionID or
> > > leave that for userspace.
> > IIUC, the UUID is the one identifying the trusted service. So what
> > purpose does partionID solves for user-space program?
> Sorry for not giving complete picture here. In the context of FF-A and secure
> partitions, there were discussions to allow single partition implementing
> multiple services/protocols(each associated with UUID) and on a system with
> multiple SPs, 2 different SPs can be implementing same protocol/service.
> Sorry if I am missing something here or if that is impossible, this is just
> my understanding and hence I was check if UUID + something(vm_id as per FF-A
> spec) need to be used to identify which partition and service we would want to
> talk to.
Okay, I see this explanation coming from FF-A spec but currently FF-A
bus in the kernel only enumerates secure partitions via UUIDs only. I
guess that needs to change first.
> > >
> > > 3. While I definitely want to move the protocol specifics from the driver
> > > (as mentioned in (1)), do we even try to remove adding UUID of each service
> > > we would like to use this driver.
> > Yes, we shouldn't hardcode any UUIDs for trusted services within the
> > driver (it isn't scalable) but rather during open sessions we should
> > search if a particular UUID is available on FF-A bus to communicate
> > with?
> Yes it is not scalable and I am aware of that. I haven't explored the
> options to get rid of them yet. Thanks for the suggestion.
> > > I haven't thought through that yet,
> > > but the idea I have is to just have a blocked UUID list which can
> > > contain UUID for OPTEE and other in-kernel users.
> > > That may need changes in FF-A bus match but something to consider ?
> > >
> > Currently in the case of OP-TEE we depend on an open session login
> > method where the particular trusted application decides whether a
> > particular login method is allowed or not, refer here  for more
> > details. I guess similar access control checks can be implemented by a
> > particular trusted service during an open session. This will allow us
> > to not maintain any allowed or blocked list.
> Thanks for the details, I will explore and see how we can use something
> similar. I will ping you if I get stuck or need more info or need more
> discussion on that.
>  https://git.trustedfirmware.org/TS/trusted-services.git