Messages in this thread | | | Date | Tue, 26 Apr 2022 15:45:45 +0100 | From | Sudeep Holla <> | Subject | Re: [PATCH] tee: Add Arm FF-A TEE driver |
| |
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@arm.com> 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[2] I am using to test with relevant changes to use these TEE APIs.
> > Cc: Jens Wiklander <jens.wiklander@linaro.org> > > Cc: Sumit Garg <sumit.garg@linaro.org> > > Co-developed-by: Balint Dobszay <balint.dobszay@arm.com> > > Signed-off-by: Balint Dobszay <balint.dobszay@arm.com> > > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > > --- > > 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.
> > > > 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 [1] 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.
-- Regards, Sudeep
[2] https://git.trustedfirmware.org/TS/trusted-services.git
| |