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?
+/**
- 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.
+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 ?
Kind regards, Abdellatif