- OP-TEE - lists.trustedfirmware.org

by Patryk

Hi, I have some problems configuring dynamic shared memory on my platform, and thought that perhaps somebody could give me a hint. My SoC (LS1028A, board: LS1028A-RDB), according to reference manual has two DRAM regions: - DRAM region 0 : start address: 0x80000000, size: 0x80000000 - DRAM region 2: start address: 0x2080000000, size: 0x1F80000000 I tried two approaches: 1) In optee-os, in a part of code that handles my SoC I added a call to register DDR only for the first region: register_addr(0x80000000, 2G - some size for TZ DRAM) (similarly like in case of other SoCs) However when the system boots up, the optee driver logs the following information: [ 5.703831] optee: dynamic shared memory is enabled E/TC:0 0 std_entry_with_parg:234 Bad arg address 0x208100e000 It seems that there is some problem with an address that the driver wants to use 2) Apart from registering first region I also added a call that registers the second region so I ended up with two calls: register_addr(0x80000000, 2G - some size for TZ DRAM) register_ddr(0x2080000000, 0x1F80000000); Now the problem is different since the platform no longer boots, due to the panic with the following output: D/TC:0 0 discover_nsec_memory:1117 No non-secure memory found in external DT D/TC:0 0 carve_out_phys_mem:362 No need to carve out 0xfc000000 size 0x3e00000 D/TC:0 0 carve_out_phys_mem:362 No need to carve out 0xffe00000 size 0x200000 E/TC:0 0 Panic at /usr/src/debug/optee-os-qoriq/4.2.0+git/core/mm/core_mmu.c:490 <core_mmu_set_discovered_nsec_ddr> I'm wondering, what am I missing? Do I need to register both regions? If so, why does the optee panic when the second region gets registered? I would be grateful for some ideas. Best regards Patryk

1 year

2
2
0 0

Linaro OP-TEE Contribution, LOC, monthly meeting January 28

by Jens Wiklander

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/ The TA-specific parts of fTPM have now been included in the first OP-TEE release in the optee_ftpm and we run fTPM in the OP-TEE OS CI loop at Github. Much of what we set out to do over half a year ago has been done, but there are some issues with the quality of the code. It doesn't compile without warnings and the coding style is inconsistent with the normal OP-TEE coding style (or anything else). Let's discuss how we can improve the status. Are there any other topics? Thanks, Jens

1 year

1
0
0 0

libtomcrypt, AES-CTR: Missing counter-increment for non-crypto-accelerated archs?

by Jork Loeser (he/him)

(Please provide a better way of reporting should this ML not be a good forum for bug-reports/fixes) Hello all, While experimenting with OP-TEE OS on a non-ARM platform (x86, to be precise), I noticed xtest regression_4003 and regression_4017 to be failing. It appears that for AES-CTR encrypt/decrypt, optee_os/core/lib/libtomcrypt/src/modes/ctr/ctr_encrypt.c:s_ctr_encrypt()<https://github.com/OP-TEE/optee_os/blob/37de1791d97d0df56db0709b5d001f82159…> fails to increment the counter on block boundaries when passed data covers a whole block. I suppose that it is a non-problem for architectures having crypto acceleration hooked up, since ctr_encrypt() bypasses s_ctr_encrypt() in that case. The below fixes the behavior for my setup - xtest regression_4003 and regression_4017 pass as a result: diff --git a/core/lib/libtomcrypt/src/modes/ctr/ctr_encrypt.c b/core/lib/libtomcrypt/src/modes/ctr/ctr_encrypt.c index a23e33c05..2019de2b6 100644 --- a/core/lib/libtomcrypt/src/modes/ctr/ctr_encrypt.c +++ b/core/lib/libtomcrypt/src/modes/ctr/ctr_encrypt.c @@ -61,6 +61,7 @@ static int s_ctr_encrypt(const unsigned char *pt, unsigned char *ct, unsigned lo ct += ctr->blocklen; len -= ctr->blocklen; ctr->padlen = ctr->blocklen; + s_ctr_increment_counter(ctr); continue; } #endif I understand that you might prefer a full PR instead. Please accept my apologies for not providing such at this time; perhaps one of the maintainers (Jerome Forissier?) can take the above into consideration instead. If in doubt, consider above change as BSD-2-Clause'd. Best, Jork Loeser, Microsoft

1 year, 1 month

2
4
0 0

OP-TEE 4.5.0 has been released

by Joakim Bech

Hi, I'm pleased to announce that I've just completed the release work and made OP-TEE version 4.5.0 available. The list of changes can be found in the changelog [1]. A summary of this release will be published shortly. The stable branch is available here [2] and the tested platforms for this release are listed here [3]. Many thanks to everyone who has contributed in any form to this release. [1] https://github.com/OP-TEE/optee_os/blob/master/CHANGELOG.md [2] https://github.com/OP-TEE/manifest/tree/4.5.0 [3] https://github.com/OP-TEE/optee_os/commit/0919de0f7c79ad35ad3c8ace5f823ad13… -- Regards, Joakim Bech | Distinguished Engineer | Linaro | | Mobile: +46 73 697 37 14 | Address: Scheelevägen 17, 223 63 Lund, Sweden |

1 year, 1 month

1
0
0 0

Preparing for OP-TEE 4.5.0

by Joakim Bech

[BCC all OP-TEE maintainers] Hi OP-TEE maintainers & contributors, OP-TEE v4.5.0 is scheduled to be released on 2025-01-17. 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/7211. As usual, we will create a release candidate tag one week before the release date for final testing (Friday this week, i.e., tomorrow). In addition to that you can find some additional information related to releases here: https://optee.readthedocs.io/en/latest/general/releases.html -- Regards, Joakim Bech | Distinguished Engineer | Linaro | | Mobile: +46 73 697 37 14 | Address: Scheelevägen 17, 223 63 Lund, Sweden |

1 year, 1 month

1
1
0 0

[GIT PULL] OP-TEE fix for v6.14

by Jens Wiklander

Hello arm-soc maintainers, Please pull this small patch fixing a version print in the optee driver. Thanks, Jens The following changes since commit fac04efc5c793dccbd07e2d59af9f90b7fc0dca4: Linux 6.13-rc2 (2024-12-08 14:03:39 -0800) are available in the Git repository at: https://git.linaro.org/people/jens.wiklander/linux-tee.git/ tags/optee-for-v6.14 for you to fetch changes up to 1ff7d092dce0b2273dce4b8d33fa5856679dd25b: optee: fix format string for printing optee build_id (2024-12-17 11:22:46 +0100) ---------------------------------------------------------------- Fix format string for printing optee build_id ---------------------------------------------------------------- Sahil Malhotra (1): optee: fix format string for printing optee build_id drivers/tee/optee/smc_abi.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)

1 year, 1 month

1
0
0 0

[PATCH 00/10] Trusted Execution Environment (TEE) driver for Qualcomm TEE (QTEE)

by Amirreza Zarrabi

This patch series introduces a Trusted Execution Environment (TEE) driver for Qualcomm TEE (QTEE). QTEE enables Trusted Applications (TAs) and services to run securely. It uses an object-based interface, where each service is an object with sets of operations. Clients can invoke these operations on objects, which can generate results, including other objects. For example, an object can load a TA and return another object that represents the loaded TA, allowing access to its services. Kernel and userspace services are also available to QTEE through a similar approach. QTEE makes callback requests that are converted into object invocations. These objects can represent services within the kernel or userspace process. Note: This patch series focuses on QTEE objects and userspace services. Linux already provides a TEE subsystem, which is described in [1]. The tee subsystem provides a generic ioctl interface, TEE_IOC_INVOKE, which can be used by userspace to talk to a TEE backend driver. We extend the Linux TEE subsystem to understand object parameters and an ioctl call so client can invoke objects in QTEE: - TEE_IOCTL_PARAM_ATTR_TYPE_OBJREF_* - TEE_IOC_OBJECT_INVOKE The existing ioctl calls TEE_IOC_SUPPL_RECV and TEE_IOC_SUPPL_SEND are used for invoking services in the userspace process by QTEE. The TEE backend driver uses the QTEE Transport Message to communicate with QTEE. Interactions through the object INVOKE interface are translated into QTEE messages. Likewise, object invocations from QTEE for userspace objects are converted into SEND/RECV ioctl calls to supplicants. The details of QTEE Transport Message to communicate with QTEE is available in [PATCH 10/10] Documentation: tee: Add Qualcomm TEE driver. This patch series has been tested for basic QTEE object invocations and callback requests, including loading a TA and requesting services form the TA. However, the test platform is currently being prepared for upstream availability and will soon be accessible to the community for further validation. I will share updates as the platform become available. [1] https://www.kernel.org/doc/Documentation/tee.txt Signed-off-by: Amirreza Zarrabi <quic_azarrabi(a)quicinc.com> --- Amirreza Zarrabi (10): tee: allow a driver to allocate a tee_device without a pool tee: add TEE_IOCTL_PARAM_ATTR_TYPE_MEMBUF tee: add TEE_IOCTL_PARAM_ATTR_TYPE_OBJREF firmware: qcom: scm: add support for object invocation qcomtee: implement object invoke support qcomtee: add primordial object dt-bindings: arm: qcomtee: add QTEE driver devicetree binding for TEE subsystem tee: add Qualcomm TEE driver arm64: dts: qcom: sm8650: add support for QTEE Documentation: tee: Add Qualcomm TEE driver .../devicetree/bindings/arm/firmware/qcom,tee.yaml | 34 + Documentation/tee/index.rst | 1 + Documentation/tee/qtee.rst | 143 ++++ arch/arm64/boot/dts/qcom/sm8650.dtsi | 4 + drivers/firmware/qcom/qcom_scm.c | 60 ++ drivers/firmware/qcom/qcom_scm.h | 7 + drivers/tee/Kconfig | 1 + drivers/tee/Makefile | 1 + drivers/tee/qcomtee/Kconfig | 10 + drivers/tee/qcomtee/Makefile | 9 + drivers/tee/qcomtee/async.c | 153 ++++ drivers/tee/qcomtee/call.c | 707 ++++++++++++++++ drivers/tee/qcomtee/core.c | 942 +++++++++++++++++++++ drivers/tee/qcomtee/primordial_obj.c | 63 ++ drivers/tee/qcomtee/qcom_scm.c | 36 + drivers/tee/qcomtee/qcomtee_msg.h | 217 +++++ drivers/tee/qcomtee/qcomtee_private.h | 218 +++++ drivers/tee/qcomtee/release.c | 66 ++ drivers/tee/qcomtee/user_obj.c | 625 ++++++++++++++ drivers/tee/tee_core.c | 113 ++- include/linux/firmware/qcom/qcom_scm.h | 9 + include/linux/firmware/qcom/qcom_tee.h | 284 +++++++ include/linux/tee_core.h | 4 + include/linux/tee_drv.h | 12 + include/uapi/linux/tee.h | 54 +- 25 files changed, 3765 insertions(+), 8 deletions(-) --- base-commit: f486c8aa16b8172f63bddc70116a0c897a7f3f02 change-id: 20241202-qcom-tee-using-tee-ss-without-mem-obj-362c66340527 Best regards, -- Amirreza Zarrabi <quic_azarrabi(a)quicinc.com>

1 year, 2 months

7
33
0 0

[PATCH] optee: fix format string for printing optee build_id

by Sahil Malhotra

There has been a recent change in OP-TEE to print 8 and 16 character commit id for 32bit and 64bit architecture respectively. In case if commit id is starting with 0 like 04d1c612ec7beaede073b8c it is printing revision as below removing leading 0 "optee: revision 4.4 (4d1c612ec7beaed)" Signed-off-by: Sahil Malhotra <sahil.malhotra(a)nxp.com> --- drivers/tee/optee/smc_abi.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/tee/optee/smc_abi.c b/drivers/tee/optee/smc_abi.c index e9456e3e74cc..eb51dc18f32d 100644 --- a/drivers/tee/optee/smc_abi.c +++ b/drivers/tee/optee/smc_abi.c @@ -1272,8 +1272,9 @@ static void optee_msg_get_os_revision(optee_invoke_fn *invoke_fn) &res.smccc); if (res.result.build_id) - pr_info("revision %lu.%lu (%08lx)", res.result.major, - res.result.minor, res.result.build_id); + pr_info("revision %lu.%lu (%0*lx)", res.result.major, + res.result.minor, (int)sizeof(res.result.build_id) * 2, + res.result.build_id); else pr_info("revision %lu.%lu", res.result.major, res.result.minor); } -- 2.34.1

1 year, 2 months

4
3
0 0

Canceled Linaro OP-TEE Contribution, LOC, monthly meeting December 24

by Jens Wiklander

Hi, The LOC meeting in December is canceled due to the holidays. Happy holidays and see you next year, Jens

1 year, 2 months

1
0
0 0

Using EFI variables stored in RPMB

by Patryk

Hi, not sure if this is a good place to ask, however I see that OPTEE developers are highly involved in this topic so I decided to ask. Short background - we've been working on an embedded system based on Layerscape 1028A SoC. On this platform we've been using TFA (bl2, el3 runtime services), OPTEE as BL32 and u-boot as BL33. In the previous, older platforms we usually stored u-boot's environment in let's say "traditional way", we just stored the env on some offset of the eMMC device, however I see that on this particular, new platform there are some better possibilities, like combining OPTEE, EDKII StandaloneMM and u-boot efivars implementation to store EFI variables in RPMB on eMMC which seems to be more secure, UEFI compliant way. The aspect I'm unsure of is - does it make sense to utilize these capabilities if we want to only use it to store some u-boot's writable env variables and not utilize features like UEFI SecureBoot (at least for now, it may change it in the future)? I would be grateful for some advice. Best regards Patryk

1 year, 2 months

2
3
0 0

2026

2025

2024

2023

2022

2021

2020

OP-TEE