OP-TEE February 2024

op-tee@lists.trustedfirmware.org

22 participants
15 discussions

by Ricardo B. Marliere

Since commit d492cc2573a0 ("driver core: device.h: make struct bus_type a const *"), the driver core can properly handle constant struct bus_type, move the tee_bus_type variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Suggested-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Ricardo B. Marliere <ricardo(a)marliere.net> --- drivers/tee/tee_core.c | 2 +- include/linux/tee_drv.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c index 792d6fae4354..e59c20d74b36 100644 --- a/drivers/tee/tee_core.c +++ b/drivers/tee/tee_core.c @@ -1226,7 +1226,7 @@ static int tee_client_device_uevent(const struct device *dev, return add_uevent_var(env, "MODALIAS=tee:%pUb", dev_id); } -struct bus_type tee_bus_type = { +const struct bus_type tee_bus_type = { .name = "tee", .match = tee_client_device_match, .uevent = tee_client_device_uevent, diff --git a/include/linux/tee_drv.h b/include/linux/tee_drv.h index 911ddf92dcee..71632e3c5f18 100644 --- a/include/linux/tee_drv.h +++ b/include/linux/tee_drv.h @@ -482,7 +482,7 @@ static inline bool tee_param_is_memref(struct tee_param *param) } } -extern struct bus_type tee_bus_type; +extern const struct bus_type tee_bus_type; /** * struct tee_client_device - tee based device --- base-commit: 716f4aaa7b48a55c73d632d0657b35342b1fefd7 change-id: 20240213-bus_cleanup-tee-c25729bbcd7f Best regards, -- Ricardo B. Marliere <ricardo(a)marliere.net>

9 months, 1 week

[PATCH v2 0/3] Replay Protected Memory Block (RPMB) subsystem

by Jens Wiklander

Hi, It's been a while since Shyam posted the last version [1] of this patch set. I've pinged Shyam, but so far I've had no reply so I'm trying to make another attempt with the RPMB subsystem. If Shyam has other changes in mind than what I'm adding here I hope we'll find a way to cover that too. I'm calling it version two of the patchset since I'm trying to address all feedback on the previous version even if I'm starting a new thread. This patch set introduces a new RPMB subsystem, based on patches from [1], [2], and [3]. The RPMB subsystem aims at providing access to RPMB partitions to other kernel drivers, in particular the OP-TEE driver. A new user space ABI isn't needed, we can instead continue using the already present ABI when writing the RPMB key during production. I've added and removed things to keep only what is needed by the OP-TEE driver. Since the posting of [3], there has been major changes in the MMC subsystem so "mmc: block: register RPMB partition with the RPMB subsystem" is in practice completely rewritten. With this OP-TEE can access RPMB during early boot instead of having to wait for user space to become available as in the current design [4]. This will benefit the efi variables [5] since we wont rely on userspace as well as some TPM issues [6] that were solved. The OP-TEE driver finds the correct RPMB device to interact with by iterating over available devices until one is found with a programmed authentication matching the one OP-TEE is using. This enables coexisting users of other RPMBs since the owner can be determined by who knows the authentication key. I've put myself as a maintainer for the RPMB subsystem as I have an interest in the OP-TEE driver to keep this in good shape. However, if you'd rather see someone else taking the maintainership that's fine too. I'll help keep the subsystem updated regardless. [1] https://lore.kernel.org/lkml/20230722014037.42647-1-shyamsaini@linux.micros… [2] https://lore.kernel.org/lkml/20220405093759.1126835-2-alex.bennee@linaro.or… [3] https://lore.kernel.org/linux-mmc/1478548394-8184-2-git-send-email-tomas.wi… [4] https://optee.readthedocs.io/en/latest/architecture/secure_storage.html#rpm… [5] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… [6] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… Thanks, Jens Changes since Shyam's RFC: * Removed the remaining leftover rpmb_cdev_*() function calls * Refactored the struct rpmb_ops with all the previous ops replaced, in some sense closer to [3] with the route_frames() op * Added rpmb_route_frames() * Added struct rpmb_frame, enum rpmb_op_result, and enum rpmb_type from [3] * Removed all functions not needed in the OP-TEE use case * Added "mmc: block: register RPMB partition with the RPMB subsystem", based on the commit with the same name in [3] * Added "optee: probe RPMB device using RPMB subsystem" for integration with OP-TEE * Moved the RPMB driver into drivers/misc/rpmb-core.c * Added my name to MODULE_AUTHOR() in rpmb-core.c * Added an rpmb_mutex to serialize access to the IDA * Removed the target parameter from all rpmb_*() functions since it's currently unused Jens Wiklander (3): rpmb: add Replay Protected Memory Block (RPMB) subsystem mmc: block: register RPMB partition with the RPMB subsystem optee: probe RPMB device using RPMB subsystem MAINTAINERS | 7 + drivers/misc/Kconfig | 9 ++ drivers/misc/Makefile | 1 + drivers/misc/rpmb-core.c | 247 ++++++++++++++++++++++++++++++ drivers/mmc/core/block.c | 177 +++++++++++++++++++++ drivers/tee/optee/core.c | 1 + drivers/tee/optee/ffa_abi.c | 2 + drivers/tee/optee/optee_private.h | 6 + drivers/tee/optee/optee_rpc_cmd.h | 33 ++++ drivers/tee/optee/rpc.c | 221 ++++++++++++++++++++++++++ drivers/tee/optee/smc_abi.c | 2 + include/linux/rpmb.h | 184 ++++++++++++++++++++++ 12 files changed, 890 insertions(+) create mode 100644 drivers/misc/rpmb-core.c create mode 100644 include/linux/rpmb.h base-commit: 41bccc98fb7931d63d03f326a746ac4d429c1dd3 -- 2.34.1

9 months, 1 week

[PATCH v2 0/4] Introduction of a remoteproc tee to load signed firmware

by Arnaud Pouliquen

Updates from the previous version [1] - fix issues reported by kernel test robot, - address Rob Herring comment on bindings. [1] https://lore.kernel.org/linux-arm-kernel/20240115135249.296822-1-arnaud.pou… 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 (4): 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 | 52 ++- drivers/remoteproc/Kconfig | 9 + drivers/remoteproc/Makefile | 1 + drivers/remoteproc/stm32_rproc.c | 233 +++++++++-- drivers/remoteproc/tee_remoteproc.c | 393 ++++++++++++++++++ include/linux/tee_remoteproc.h | 99 +++++ 6 files changed, 740 insertions(+), 47 deletions(-) create mode 100644 drivers/remoteproc/tee_remoteproc.c create mode 100644 include/linux/tee_remoteproc.h base-commit: 0dd3ee31125508cd67f7e7172247f05b7fd1753a -- 2.25.1

9 months, 1 week

Why UBSAN is marked as using a lot of memory?

by Igor Zhbanov

Hello, In the configuration makefile mk/config.mk there are following lines: # Enable support for detected undefined behavior in C # Uses a lot of memory, can't be enabled by default CFG_CORE_SANITIZE_UNDEFINED ?= n I've read the sources of the conditionally compiled ubsan.c and, IIUC, how UBSAN is working (mostly by adding simple checks), I don't understand, why UBSAN is marked as using a lot of memory. Is this comment still valid? Thank you.

9 months, 2 weeks

Re: [TF-A] Re: Handling of normal world interrupts with BL31 PSCI handler

by Olivier Deprez

Hi, Cc the OP-TEE mailing list, as I sense this might be more of an OP-TEE (/ OPTEED) design question than TF-A generic. I agree with Manish/Achin the best way to eliminate the return by NS interrupt while OP-TEE kernel runs handling a PSCI request is to mask interrupts globally in the GIC e.g. from within opteed_system_reset? Additional questions: On https://github.com/ARM-software/arm-trusted-firmware/blob/master/lib/psci/p… The PSCI layer calls into OP-TEE SPD and then resumes OP-TEE to handle the PSCI call in a platform defined manner. As suggested here https://github.com/ARM-software/arm-trusted-firmware/blob/master/services/s… , it looks this invocation is not supposed to return into TF-A? Did you redefine the weak psci_system_reset function within OP-TEE for your platform? Is this function designed to end up in a loop and never returns to TF-A? As a side question, is this an issue that the TF-A's PSCI platform hook is possibly never called https://github.com/ARM-software/arm-trusted-firmware/blob/master/lib/psci/p… ? Regards, Olivier. ________________________________ From: Neely, Brian via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 13 November 2023 19:01 To: Manish Pandey2 <Manish.Pandey2(a)arm.com>; tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>; Ethridge, Caleb <Caleb.Ethridge(a)analog.com> Subject: [TF-A] Re: Handling of normal world interrupts with BL31 PSCI handler Hi Manish, Just following up on your comment below. Are you planning to provide guidance as to which PSCI calls should have NS interrupts masked? Are these changes that should go in the mainline TF-A repo, or do you believe they are specific to our use case? Thanks, Brian From: Manish Pandey2 via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: Friday, November 10, 2023 11:31 AM To: tf-a(a)lists.trustedfirmware.org; Ethridge, Caleb <Caleb.Ethridge(a)analog.com> Subject: [TF-A] Re: Handling of normal world interrupts with BL31 PSCI handler [External] Hi Caleb, The quick answer to your query is to mask the NS interrupts in BL31 (option a), You should not remove the callback to OPTEE as it may need to do its own state maintained before system RESET. There are other scenarios in PSCI (e.g. CPU power down) path which need to consider disabling NS interrupts before invoking Secure world hooks, will provide further analysis on those later. Thanks Manish Pandey ________________________________ From: Caleb Ethridge via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Sent: 10 November 2023 15:12 To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: [TF-A] Handling of normal world interrupts with BL31 PSCI handler Hello, If normal world interrupts are received while invoking TF-A's PSCI reset handler, we have observed that the reset can be aborted. In TF-A's PSCI reset handler, a call out to OP-TEE is made before performing the platform-specific reset: https://github.com/ARM-software/arm-trusted-firmware/blob/master/lib/psci/p…<https://urldefense.com/v3/__https:/github.com/ARM-software/arm-trusted-firm…> https://github.com/ARM-software/arm-trusted-firmware/blob/master/services/s…<https://urldefense.com/v3/__https:/github.com/ARM-software/arm-trusted-firm…> When OP-TEE is entered, it is possible to receive foreign (normal world) interrupts, which invokes the procedure described here: https://optee.readthedocs.io/en/3.16.0/architecture/core.html#deliver-non-s…<https://urldefense.com/v3/__https:/optee.readthedocs.io/en/3.16.0/architect…> When the SMC call is aborted as described above, this results in the reboot failing. Linux does not retry the PSCI reset (https://github.com/torvalds/linux/blob/master/drivers/firmware/psci/psci.c#…<https://urldefense.com/v3/__https:/github.com/torvalds/linux/blob/master/dr…>). This makes sense because it is not expecting the SMC call to fail (it expected to make an uninterruptable SMC call into the secure monitor, not a call into OP-TEE). If OP-TEE itself is setup to handle PSCI reset calls, it also handles them in (uninterruptable) SMC context: https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/sm/psci.c#L140<https://urldefense.com/v3/__https:/github.com/OP-TEE/optee_os/blob/master/c…> https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/sm/sm_a32.S#L96<https://urldefense.com/v3/__https:/github.com/OP-TEE/optee_os/blob/master/c…> Based on this, we see two possible solutions: a) Masking the non-secure interrupts in BL31 while we are doing a reset b) Removing the call to OPTEE in the reset handler so that we never leave the SMC context Which option do you suggest? Or are we missing an important detail here? Thanks, Caleb -- TF-A mailing list -- tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> To unsubscribe send an email to tf-a-leave(a)lists.trustedfirmware.org<mailto:tf-a-leave@lists.trustedfirmware.org>

9 months, 3 weeks

2024

2023

2022

2021

2020

OP-TEE February 2024