Hi all,
We can reproduce the reported use-after-free issue on our platform via an
overnight reboot test
The verifications are listed as the following
- With v2 + Michael Wu's patch: Issue resolved.
- With v4: Race condition observation and already report to Amir
- With v5: Race fixed. Stable in our tests, including:
xtest + reboot loop (300 cycles)
continuous reboot test (1000 cycles)
No regressions observed with v5.
If there are no other concerns, we recommend adopting v5.
If needed, please add the following tag:
Tested-by: Ox Yeh <ox.yeh(a)mediatek.com>
Yuanjia Yeh
Hi,
Tomorrow, Tuesday, it's time for another LOC monthly meeting. For time
and connection details, see the calendar at
https://www.trustedfirmware.org/meetings/
- Rebased linaro-swg/kernel optee branch on v6.18
Any other topics?
Cheers,
Jens
Main updates from version V19[3]:
--------------------------------
The devicetree is now structured as follows:
firmware {
optee {
compatible = "linaro,optee-tz";
method = "smc";
#address-cells = <1>;
#size-cells = <0>;
rproc-service@0 {
compatible = "rproc-service-80a4c275-0a47-4905-8285-1486a9771a08";
reg = <0>;
#address-cells = <1>;
#size-cells = <0>;
status = "okay";
m4: m4@0 {
compatible = "st,stm32mp15-m4-tee";
reg = <0>;
mboxes = <&ipcc 0>, <&ipcc 1>, <&ipcc 2>;
mbox-names = "vq0", "vq1", "shutdown";
memory-region = <&vdev0vring0>, <&m_ipc_shm>, <&mcuram2>,
<&vdev0vring1>, <&vdev0buffer>, <&retram>;
interrupt-parent = <&exti>;
interrupts = <68 1>;
status = "okay";
};
};
};
};
As a consequence, this version:
- Introduces a new stm32_rproc_tee.c remoteproc driver.
Instead of further complicating the existing stm32_rproc.c driver, a
dedicated TEE-based driver is added. Both drivers are intended to also
support the STM32MP2x Cortex-M33 remote processor in a next step.
- Reworks the bindings:
- Drop the st,stm32-rproc.yaml updates that were introduced in previous
revisions.
- Add remoteproc-tee.yaml for the
"rproc-service-80a4c275-0a47-4905-8285-1486a9771a08" compatible.
- Add st,stm32-rproc-tee.yaml for the "st,stm32mp15-m4-tee" compatible.
- Reworks the probing sequence:
The m4@0 device is now probed by the remoteproc-tee driver, which itself
is instantiated by the TEE (OP-TEE) bus.
Main updates from version V18[2]:
--------------------------------
- rework documentation for the release_fw ops
- rework function documentation in remoteproc_tee.c
- replace spinlock by mutex and generalize usage in remoteproc_tee.c
Main updates from version V17[1]:
--------------------------------
- Fix: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h>
is missing
More details are available in each patch commit message.
[1] https://lore.kernel.org/linux-remoteproc/20250613091650.2337411-1-arnaud.po…
[2] https://lore.kernel.org/linux-remoteproc/20250616075530.4106090-1-arnaud.po…
[3] https://lore.kernel.org/linux-devicetree/20250625094028.758016-1-arnaud.pou…
Tested-on:
---------
commit 7d0a66e4bb90 ("Linux 6.18")
Description of the feature:
--------------------------
This series proposes the implementation of a remoteproc tee driver to
communicate with a TEE trusted application responsible for authenticating
and loading the remoteproc firmware image in an Arm secure context.
1) Principle:
The remoteproc tee driver provides services to communicate with the OP-TEE
trusted application running on the Trusted Execution Context (TEE).
The trusted application in TEE manages the remote processor lifecycle:
- authenticating and loading firmware images,
- isolating and securing the remote processor memories,
- supporting multi-firmware (e.g., TF-M + Zephyr on a Cortex-M33),
- managing the start and stop of the firmware by the TEE.
2) Format of the signed image:
Refer to:
https://github.com/OP-TEE/optee_os/blob/master/ta/remoteproc/src/remoteproc…
3) OP-TEE trusted application API:
Refer to:
https://github.com/OP-TEE/optee_os/blob/master/ta/remoteproc/include/ta_rem…
4) OP-TEE signature script
Refer to:
https://github.com/OP-TEE/optee_os/blob/master/scripts/sign_rproc_fw.py
Example of usage:
sign_rproc_fw.py --in <fw1.elf> --in <fw2.elf> --out <signed_fw.sign> --key ${OP-TEE_PATH}/keys/default.pem
5) Impact on User space Application
No sysfs impact. The user only needs to provide the signed firmware image
instead of the ELF image.
For more information about the implementation, a presentation is available here
(note that the format of the signed image has evolved between the presentation
and the integration in OP-TEE).
https://resources.linaro.org/en/resource/6c5bGvZwUAjX56fvxthxds
Arnaud Pouliquen (6):
dt-bindings: firmware: Add TEE remoteproc service binding
dt-bindings: remoteproc: Add STM32 TEE-controlled rproc binding
remoteproc: core: Introduce rproc_pa_to_va helper
remoteproc: Introduce optional release_fw operation
remoteproc: Add TEE support
remoteproc: stm32: Add TEE-controlled STM32 driver
.../arm/firmware/linaro,optee-tz.yaml | 6 +
.../bindings/remoteproc/remoteproc-tee.yaml | 47 ++
.../remoteproc/st,stm32-rproc-tee.yaml | 100 +++
drivers/remoteproc/Kconfig | 10 +
drivers/remoteproc/Makefile | 3 +-
drivers/remoteproc/remoteproc_core.c | 52 ++
drivers/remoteproc/remoteproc_internal.h | 6 +
drivers/remoteproc/remoteproc_tee.c | 771 ++++++++++++++++++
drivers/remoteproc/stm32_rproc_tee.c | 526 ++++++++++++
include/linux/remoteproc.h | 6 +
include/linux/remoteproc_tee.h | 89 ++
11 files changed, 1615 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/remoteproc/remoteproc-tee.yaml
create mode 100644 Documentation/devicetree/bindings/remoteproc/st,stm32-rproc-tee.yaml
create mode 100644 drivers/remoteproc/remoteproc_tee.c
create mode 100644 drivers/remoteproc/stm32_rproc_tee.c
create mode 100644 include/linux/remoteproc_tee.h
base-commit: 7d0a66e4bb9081d75c82ec4957c50034cb0ea449
--
2.43.0
When we do SCMI on OP-TEE, the in buffer and out buffer are the same buffer.
I added some debug code to confirm this:
diff --git a/module/msg_smt/src/mod_msg_smt.c b/module/msg_smt/src/mod_msg_smt.c
index 853fe66b8d27..1e92dcd49c29 100644
--- a/module/msg_smt/src/mod_msg_smt.c
+++ b/module/msg_smt/src/mod_msg_smt.c
@@ -175,6 +175,11 @@ static int smt_write_payload(fwk_id_t channel_id,
if (!channel_ctx->locked)
return FWK_E_ACCESS;
+ FWK_LOG_ERR("OUT=%p IN=%p %s",
+ channel_ctx->out->payload,
+ channel_ctx->in->payload,
+ (channel_ctx->out->payload == channel_ctx->in->payload) ? "equal" : "different");
+
memcpy(((uint8_t*)channel_ctx->out->payload) + offset, payload, size);
return FWK_SUCCESS;
And it's true:
[ 0.000000] OUT=0x9c401004 IN=0x9c401004 equal
This normally isn't a problem because we read a few inputs at the
start of the function and then write out the result to the output at the
end.
But in the scmi_pin_control_list_associations_handler() it does a loop
where each iteration reads from parameters->index which is input and
writes to the output with scmi_pin_control_ctx.scmi_api->write_payload()
and that corrupts the input data.
Copying the input buffer to a the stack the issue for me, but I feel
like it is a hack. It would be better to use separate buffers for
input and output.
I think this comes from:
https://github.com/OP-TEE/optee_os/blob/master/core/kernel/pseudo_ta.c#L93
I added a print statement to there as well:
diff --git a/core/kernel/pseudo_ta.c b/core/kernel/pseudo_ta.c
index 587faa41a770..426870fb934c 100644
--- a/core/kernel/pseudo_ta.c
+++ b/core/kernel/pseudo_ta.c
@@ -90,6 +90,7 @@ static TEE_Result copy_in_param(struct ts_session *s __maybe_unused,
va = NULL;
}
+ EMSG("n=%lu va=%p", n, va);
tee_param[n].memref.buffer = va;
tee_param[n].memref.size = mem->size;
break;
E/TC:? 0 copy_in_param:93 n=1 va=0x9c401000
E/TC:? 0 copy_in_param:93 n=2 va=0x9c401000
Here is the patch to save "parameters" to a different buffer.
---
.../scmi_pin_control/src/mod_scmi_pin_control.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/module/scmi_pin_control/src/mod_scmi_pin_control.c b/module/scmi_pin_control/src/mod_scmi_pin_control.c
index a0b90dd2b73f..54e613b70f69 100644
--- a/module/scmi_pin_control/src/mod_scmi_pin_control.c
+++ b/module/scmi_pin_control/src/mod_scmi_pin_control.c
@@ -344,7 +344,7 @@ static int scmi_pin_control_list_associations_handler(
fwk_id_t service_id,
const uint32_t *payload)
{
- const struct scmi_pin_control_list_associations_a2p *parameters;
+ const struct scmi_pin_control_list_associations_a2p parameters;
uint32_t payload_size;
uint16_t identifiers_count;
uint16_t total_number_of_associations;
@@ -362,8 +362,9 @@ static int scmi_pin_control_list_associations_handler(
payload_size = (uint32_t)sizeof(return_values);
parameters = (const struct scmi_pin_control_list_associations_a2p *)payload;
+ memcpy(¶meters, payload, sizeof(parameters));
- status = map_identifier(parameters->identifier, &mapped_identifier);
+ status = map_identifier(parameters.identifier, &mapped_identifier);
if (status != FWK_SUCCESS) {
return_values.status = SCMI_NOT_FOUND;
@@ -371,7 +372,7 @@ static int scmi_pin_control_list_associations_handler(
}
status = scmi_pin_control_ctx.pinctrl_api->get_total_number_of_associations(
- mapped_identifier, parameters->flags, &total_number_of_associations);
+ mapped_identifier, parameters.flags, &total_number_of_associations);
if (status != FWK_SUCCESS) {
return_values.status = SCMI_NOT_FOUND;
goto exit;
@@ -388,11 +389,11 @@ static int scmi_pin_control_list_associations_handler(
identifiers_count = (uint16_t)FWK_MIN(
buffer_allowed_identifiers,
- (uint16_t)(total_number_of_associations - parameters->index));
+ (uint16_t)(total_number_of_associations - parameters.index));
return_values.flags = identifiers_count;
return_values.flags |= SHIFT_LEFT_BY_POS(
- (total_number_of_associations - parameters->index - identifiers_count),
+ (total_number_of_associations - parameters.index - identifiers_count),
NUM_OF_REMAINING_ELEMENTS_POS);
for (identifier_index = 0; identifier_index < identifiers_count;
@@ -401,8 +402,8 @@ static int scmi_pin_control_list_associations_handler(
status = scmi_pin_control_ctx.pinctrl_api->get_list_associations(
mapped_identifier,
- parameters->flags,
- (parameters->index + identifier_index),
+ parameters.flags,
+ (parameters.index + identifier_index),
&object_id);
if (status != FWK_SUCCESS) {
return_values.status = SCMI_NOT_FOUND;
--
2.51.0