On Tue, 26 Apr 2022 at 20:15, Sudeep Holla sudeep.holla@arm.com 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@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.
AFAIR, there is a concept of trusted services being launched by OP-TEE as well [1]. Is it the environment you are testing this interface with?
[1] https://developer.trustedfirmware.org/w/trusted-services/op-tee-spmc/
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:
- 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.
- 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.
-Sumit
- 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