Hi Abdellatif,
On Wed, Aug 13, 2025 at 05:42:58PM +0100, Abdellatif El Khlifi wrote:
Hi Arnaud,
Add a remoteproc TEE (Trusted Execution Environment) driver that will be probed by the TEE bus. If the associated Trusted application is supported on the secure part, this driver offers a client interface to load firmware by the secure part. This firmware could be authenticated by the secure trusted application.
A specificity of the implementation is that the firmware has to be authenticated and optionally decrypted to access the resource table.
Consequently, the boot sequence is:
rproc_parse_fw --> rproc_tee_parse_fw remoteproc TEE:
- Requests the TEE application to authenticate and load the firmware in the remote processor memories.
- Requests the TEE application for the address of the resource table.
- Creates a copy of the resource table stored in rproc->cached_table.
rproc_load_segments --> rproc_tee_load_fw remoteproc TEE:
- Requests the TEE application to load the firmware. Nothing is done at the TEE application as the firmware is already loaded.
- In case of recovery, the TEE application has to reload the firmware.
rproc_tee_get_loaded_rsc_table remoteproc TEE requests the TEE application for the address of the resource table.
rproc_start --> rproc_tee_start
- Requests the TEE application to start the remote processor.
The shutdown sequence is:
rproc_stop --> rproc_tee_stop
- Requests the TEE application to stop the remote processor.
rproc_tee_release_fw This function is used to request the TEE application to perform actions to return to the initial state on stop or on error during the boot sequence.
Signed-off-by: Arnaud Pouliquen arnaud.pouliquen@foss.st.com
...
+static const struct tee_client_device_id rproc_tee_id_table[] = {
- {UUID_INIT(0x80a4c275, 0x0a47, 0x4905, 0x82, 0x85, 0x14, 0x86, 0xa9, 0x77, 0x1a, 0x08)},
- {}
+};
Other implementations may use different UUIDs. What about adding a kernel configuration option which, when enabled, allows alternative implementations to override this table?
You don't need any other kernel configuration option for table override but rather you extend this table with UUID for service provided by TS-TEE.
+/**
- rproc_tee_register() - Register a remote processor controlled by the TEE application.
...
+static int rproc_tee_ctx_match(struct tee_ioctl_version_data *ver, const void *data) +{
- /* Today we support only the OP-TEE, could be extend to other tees */
- return (ver->impl_id == TEE_IMPL_ID_OPTEE);
+}
Could we make ver->impl_id user-configurable please ? for example, by reading it from the device tree since it isn’t discoverable at runtime? In our setup, we’d set it to TEE_IMPL_ID_TSTEE.
In case the TS-TEE service gets enumerated on TEE bus then the ver->impl_id will get automatically configured to TEE_IMPL_ID_TSTEE. It is how the driver will get to know if it is communicating with an OP-TEE based service of TS-TEE based service.
+static int rproc_tee_probe(struct device *dev) +{
- struct tee_context *tee_ctx;
- int ret;
- /* Open context with TEE driver */
- tee_ctx = tee_client_open_context(NULL, rproc_tee_ctx_match, NULL, NULL);
- if (IS_ERR(tee_ctx))
return PTR_ERR(tee_ctx);- ret = mutex_lock_interruptible(&ctx_lock);
- if (ret)
return ret;In some TEEs, the client driver might need to perform extra work during probing. For example, when using TS TEE, calling tee_shm_alloc_kernel_buf() is required. Could we introduce an rproc_tee_ops and add a TEE probe operation called by the remoteproc driver for performing custom TEE setup ?
Sure, as I mentioned above the driver will be able to know if it's communicating with TS-TEE then the additional functionality needed can be conditionally implemented during probe.
I think it is really the next step after this patch-set lands where we have to support the remoteproc service hosted under different TEE implementations like OP-TEE, TS-TEE or QTEE etc.
-Sumit