Main updates from version V7[1]
Update the series based on Mathieu Poirier's comments.
Details of the updates are listed in the commit messages of the patches.
[1] https://lore.kernel.org/linux-arm-kernel/20240611073904.475019-1-arnaud.pou…
base-commit: 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0
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 (5):
remoteproc: core: Introduce rproc_pa_to_va helper
remoteproc: Add TEE support
dt-bindings: remoteproc: Add compatibility for TEE support
remoteproc: stm32: Create sub-functions to request shutdown and
release
remoteproc: stm32: Add support of an OP-TEE TA to load the firmware
.../bindings/remoteproc/st,stm32-rproc.yaml | 58 ++-
drivers/remoteproc/Kconfig | 10 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/remoteproc_core.c | 46 ++
drivers/remoteproc/remoteproc_tee.c | 446 ++++++++++++++++++
drivers/remoteproc/stm32_rproc.c | 147 ++++--
include/linux/remoteproc.h | 5 +
include/linux/remoteproc_tee.h | 100 ++++
8 files changed, 769 insertions(+), 44 deletions(-)
create mode 100644 drivers/remoteproc/remoteproc_tee.c
create mode 100644 include/linux/remoteproc_tee.h
base-commit: 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0
--
2.25.1
[BCC all OP-TEE maintainers]
Hi OP-TEE maintainers & contributors,
OP-TEE v4.3.0 is scheduled to be released on 2024-07-12. So, now is
a good time to start testing the master branch on the various platforms
and report/fix any bugs.
The GitHub pull request for collecting Tested-by tags or any other
comments is https://github.com/OP-TEE/optee_os/pull/6906.
As usual, we will create a release candidate tag one week before the
release date for final testing.
In addition to that you can find some additional information related to
releases here: https://optee.readthedocs.io/en/latest/general/releases.html
Thanks,
Jens
Hello arm-soc maintainers,
Please pull this small patch fixing a few missing-field-initializers warnings
in the optee driver.
Thanks,
Jens
The following changes since commit a38297e3fb012ddfa7ce0321a7e5a8daeb1872b6:
Linux 6.9 (2024-05-12 14:12:29 -0700)
are available in the Git repository at:
https://git.linaro.org/people/jens.wiklander/linux-tee.git/ tags/optee-fix-for-v6.11
for you to fetch changes up to e0556255a53d6d3d406a28362dffd972018a997c:
tee: optee: ffa: Fix missing-field-initializers warning (2024-06-27 10:27:31 +0200)
----------------------------------------------------------------
Fix optee missing-field-initializers warning
----------------------------------------------------------------
Mark-PK Tsai (1):
tee: optee: ffa: Fix missing-field-initializers warning
drivers/tee/optee/ffa_abi.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
Hello arm-soc maintainers,
Please pull this small patch to the OP-TEE driver that adds a timemout
parameter when OP-TEE is waiting for a notification via RPC.
Thanks,
Jens
The following changes since commit a38297e3fb012ddfa7ce0321a7e5a8daeb1872b6:
Linux 6.9 (2024-05-12 14:12:29 -0700)
are available in the Git repository at:
https://git.linaro.org/people/jens.wiklander/linux-tee.git/ tags/optee-notif-wait-timeout-for-v6.11
for you to fetch changes up to 14ca6401d8703725c7297dcc4bf8de73323411ac:
optee: add timeout value to optee_notif_wait() to support timeout (2024-05-30 10:19:28 +0200)
----------------------------------------------------------------
optee: add timeout parameter for notification wait
----------------------------------------------------------------
Gavin Liu (1):
optee: add timeout value to optee_notif_wait() to support timeout
drivers/tee/optee/notif.c | 9 +++++++--
drivers/tee/optee/optee_private.h | 5 ++++-
drivers/tee/optee/optee_rpc_cmd.h | 1 +
drivers/tee/optee/rpc.c | 10 ++++++++--
4 files changed, 20 insertions(+), 5 deletions(-)
Hi Guys,
I am working on enabling BTI (and PAC) in trusted-services and I have a question about the topic.
If BTI is disabled in OPTEE, but someone tries to load an SP which was compiled with BTI (contains the related gnu note property) it will be successful.
This seems to be a security rish and I am thinking of either panicking or at least sending an error message to remind the user that the requested protection will not be enabled.
As I know there are common parts between TA-s and SP-s loaded by ldelf so I am not sure whether panicking in this scenario will result in any problems or not.
What do you think of this proposal?
Do you know of any reasons why BTI protected SP-s should be loadable by BTI disabled OPTEE?
Thanks in advance!
Gábor