- OP-TEE - lists.trustedfirmware.org

[PATCH] hwrng: tpm: Do not enable by default

by Jan Kiszka

From: Jan Kiszka <jan.kiszka(a)siemens.com> As seen with optee_ftpm, which uses ms-tpm-20-ref [1], a TPM may write the current time epoch to its NV storage every 4 seconds if there are commands sent to it. The 60 seconds periodic update of the entropy pool that the hwrng kthread does triggers this, causing about 4 writes per requests. Makes 2 millions per year for a 24/7 device, and that is a lot for its backing NV storage. It is therefore better to make the user intentionally enable this, providing a chance to read the warning. [1] https://github.com/Microsoft/ms-tpm-20-ref Signed-off-by: Jan Kiszka <jan.kiszka(a)siemens.com> --- drivers/char/tpm/Kconfig | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig index 8a8f692b6088..d64c929cacbe 100644 --- a/drivers/char/tpm/Kconfig +++ b/drivers/char/tpm/Kconfig @@ -45,13 +45,17 @@ config TCG_TPM2_HMAC config HW_RANDOM_TPM bool "TPM HW Random Number Generator support" depends on TCG_TPM && HW_RANDOM && !(TCG_TPM=y && HW_RANDOM=m) - default y help This setting exposes the TPM's Random Number Generator as a hwrng device. This allows the kernel to collect randomness from the TPM at boot, and provides the TPM randomines in /dev/hwrng. - If unsure, say Y. + WARNING: Specifically firmware-based TPMs, possibly also hardware + variants, can wear-out from the frequent requests issued by the + Hardware Random Number Generator Core when filling the kernel's + entropy pool. These requests are sent once every minute by default, + and the TPM may write the current time to its NV storage for each of + them. config TCG_TIS_CORE tristate -- 2.51.0

1 day, 1 hour

4
11
0 0

dma_heap and protected memory

by Amirreza Zarrabi

Hi Jens, Recently protected heap support has been added for the TEE subsystem. This allows dma-heaps to be managed by the TEE subsystem itself. For standard, non-protected heaps such as the system heap or CMA heap, I am trying to understand the expected usage model. One possible workaround appears to be to mmap the dma-buf fd in userspace, then register the resulting userspace VA with the TEE subsystem to obtain a TEE shared-memory object, for example: fd = dma_heap_alloc(...); va = mmap(fd, ...); shm_fd = tee_shm_register(va, size); tee_invoke(shm_fd); close(shm_fd); munmap(va, size); close(fd); This seems reasonable when the lifetime of the registered shared memory is limited to a single invocation or callback. However, I am concerned about cases (multiple exits in qcomtee) where the TEE side needs to retain access to the memory after the ioctl/invocation returns. In that case, registering only the userspace VA does not appear to keep the underlying dma-buf object alive. The TEE core pins the pages, but it does not hold a dma-buf reference or attachment. If userspace later closes the dma-buf fd and unmaps the VA, the dma-buf exporter may consider the buffer released, while the TEE side may still have the memory registered. Is there a recommended way to use standard heaps, such as the system or CMA dma-buf heaps, when the sharing lifetime is longer than a single TEE call? Would it make sense to extend tee_shm_register_fd() so that it can handle dma-buf fds from regular dma-heaps as well, not only dma-bufs managed by the TEE subsystem? That would allow the TEE core or backend driver to keep the dma-buf reference for the lifetime of the TEE shared-memory object. Best regards, Amir

1 day, 19 hours

1
0
0 0

[PATCH] tee: qcomtee: add missing va_end in early return qcomtee_object_user_init()

by Robertus Diawan Chris

qcomtee_object_user_init() is a variadic function and when the function return because there's no dispatch callback in QCOMTEE_OBJECT_TYPE_CB case, there's no va_end to cleanup "ap" object initialized by va_start and that can cause undefined behavior. So make sure to use va_end before returning the error code when there's no dispatch callback. This is reported by Coverity Scan as "Missing varargs init or cleanup". Fixes: d6e290837e50 ("tee: add Qualcomm TEE driver") Signed-off-by: Robertus Diawan Chris <robertusdchris(a)gmail.com> --- I don't have the device, so I am not sure how to test this change. Thank you. drivers/tee/qcomtee/core.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/tee/qcomtee/core.c b/drivers/tee/qcomtee/core.c index b1cb50e434f0..901a31e8201f 100644 --- a/drivers/tee/qcomtee/core.c +++ b/drivers/tee/qcomtee/core.c @@ -306,8 +306,10 @@ int qcomtee_object_user_init(struct qcomtee_object *object, break; case QCOMTEE_OBJECT_TYPE_CB: object->ops = ops; - if (!object->ops->dispatch) - return -EINVAL; + if (!object->ops->dispatch) { + ret = -EINVAL; + goto out; + } /* If failed, "no-name". */ object->name = kvasprintf_const(GFP_KERNEL, fmt, ap); @@ -320,6 +322,8 @@ int qcomtee_object_user_init(struct qcomtee_object *object, default: ret = -EINVAL; } + +out: va_end(ap); return ret; base-commit: 5d6919055dec134de3c40167a490f33c74c12581 -- 2.54.0

1 day, 20 hours

2
2
0 0

[PATCH v5 00/16] firmware: qcom: Add OP-TEE PAS service support

by Sumit Garg

From: Sumit Garg <sumit.garg(a)oss.qualcomm.com> Qcom platforms has the legacy of using non-standard SCM calls splintered over the various kernel drivers. These SCM calls aren't compliant with the standard SMC calling conventions which is a prerequisite to enable migration to the FF-A specifications from Arm. OP-TEE as an alternative trusted OS to Qualcomm TEE (QTEE) can't support these non-standard SCM calls. And even for newer architectures using S-EL2 with Hafnium support, QTEE won't be able to support SCM calls either with FF-A requirements coming in. And with both OP-TEE and QTEE drivers well integrated in the TEE subsystem, it makes further sense to reuse the TEE bus client drivers infrastructure. The added benefit of TEE bus infrastructure is that there is support for discoverable/enumerable services. With that client drivers don't have to manually invoke a special SCM call to know the service status. So enable the generic Peripheral Authentication Service (PAS) provided by the firmware. It acts as the common layer with different TZ backends plugged in whether it's an SCM implementation or a proper TEE bus based PAS service implementation. The TEE PAS service ABI is designed to be extensible with additional API as PTA_QCOM_PAS_CAPABILITIES. This allows to accommodate any future extensions of the PAS service needed while still maintaining backwards compatibility. Currently OP-TEE support is being added to provide the backend PAS service implementation which can be found as part of this PR [1]. This implementation has been tested on Kodiak/RB3Gen2 board with lemans EVK board being the next target. In addition to that WIN/IPQ targets planning to use OP-TEE will use this service too. Surely the backwards compatibility is maintained and tested for SCM backend. Note that kernel PAS service support while running in EL2 is at parity among OP-TEE vs QTEE. Especially the media (venus/iris) support depends on proper IOMMU support being worked out on the PAS client end. Patch summary: - Patch #1: adds Kodiak EL2 overlay since boot stack with TF-A/OP-TEE only allow UEFI and Linux to boot in EL2. - Patch #2: adds generic PAS service. - Patch #3: migrates SCM backend to generic PAS service. - Patch #4: adds TEE/OP-TEE backend for generic PAS service. - Patch #5-#14: migrates all client drivers to generic PAS service. - Patch #15: drops legacy PAS SCM exported APIs. The patch-set is based on v7.1-rc1 tag and can be found in git tree here [2]. Merge strategy: It is expected due to APIs dependency, the entire patch-set to go via the Qcom tree. All other subsystem maintainers, it will be great if I can get acks for the corresponding subsystem patches. [1] https://github.com/OP-TEE/optee_os/pull/7721 (already merged) [2] https://git.kernel.org/pub/scm/linux/kernel/git/sumit.garg/linux.git/log/?h… --- Changes in v5: - Incorporated misc. comments from Mukesh. - Split up patch #11 into 2 to add an independent commit for passing proper PAS ID to set_remote_state API. - Picked up tags. Changes in v4: - Incorporate misc. comments on patch #4. - Picked up an ack for patch #10. - Clarify in cover letter about state of media support. Changes in v3: - Incorporated some style and misc. comments for patch #2, #3 and #4. - Add QCOM_PAS Kconfig dependency for various subsystems. - Switch from pseudo TA to proper TA invoke commands. Changes in v2: - Fixed kernel doc warnings. - Polish commit message and comments for patch #2. - Pass proper PAS ID in set_remote_state API for media firmware drivers. - Added Maintainer entry and dropped MODULE_AUTHOR. Mukesh Ojha (1): arm64: dts: qcom: kodiak: Add EL2 overlay Sumit Garg (15): firmware: qcom: Add a generic PAS service firmware: qcom_scm: Migrate to generic PAS service firmware: qcom: Add a PAS TEE service remoteproc: qcom_q6v5_pas: Switch over to generic PAS TZ APIs remoteproc: qcom_q6v5_mss: Switch to generic PAS TZ APIs soc: qcom: mdtloader: Switch to generic PAS TZ APIs remoteproc: qcom_wcnss: Switch to generic PAS TZ APIs remoteproc: qcom: Select QCOM_PAS generic service drm/msm: Switch to generic PAS TZ APIs media: qcom: Switch to generic PAS TZ APIs media: qcom: Pass proper PAS ID to set_remote_state API net: ipa: Switch to generic PAS TZ APIs wifi: ath12k: Switch to generic PAS TZ APIs firmware: qcom_scm: Remove SCM PAS wrappers MAINTAINERS: Add maintainer entry for Qualcomm PAS TZ service MAINTAINERS | 9 + arch/arm64/boot/dts/qcom/Makefile | 2 + arch/arm64/boot/dts/qcom/kodiak-el2.dtso | 35 ++ drivers/firmware/qcom/Kconfig | 19 + drivers/firmware/qcom/Makefile | 2 + drivers/firmware/qcom/qcom_pas.c | 291 +++++++++++ drivers/firmware/qcom/qcom_pas.h | 50 ++ drivers/firmware/qcom/qcom_pas_tee.c | 476 ++++++++++++++++++ drivers/firmware/qcom/qcom_scm.c | 302 ++++------- drivers/gpu/drm/msm/Kconfig | 1 + drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 4 +- drivers/gpu/drm/msm/adreno/adreno_gpu.c | 11 +- drivers/media/platform/qcom/iris/Kconfig | 25 +- .../media/platform/qcom/iris/iris_firmware.c | 9 +- drivers/media/platform/qcom/venus/Kconfig | 1 + drivers/media/platform/qcom/venus/firmware.c | 11 +- drivers/net/ipa/Kconfig | 2 +- drivers/net/ipa/ipa_main.c | 13 +- drivers/net/wireless/ath/ath12k/Kconfig | 2 +- drivers/net/wireless/ath/ath12k/ahb.c | 8 +- drivers/remoteproc/Kconfig | 4 +- drivers/remoteproc/qcom_q6v5_mss.c | 5 +- drivers/remoteproc/qcom_q6v5_pas.c | 51 +- drivers/remoteproc/qcom_wcnss.c | 12 +- drivers/soc/qcom/mdt_loader.c | 12 +- include/linux/firmware/qcom/qcom_pas.h | 43 ++ include/linux/firmware/qcom/qcom_scm.h | 29 -- include/linux/soc/qcom/mdt_loader.h | 6 +- 28 files changed, 1117 insertions(+), 318 deletions(-) create mode 100644 arch/arm64/boot/dts/qcom/kodiak-el2.dtso create mode 100644 drivers/firmware/qcom/qcom_pas.c create mode 100644 drivers/firmware/qcom/qcom_pas.h create mode 100644 drivers/firmware/qcom/qcom_pas_tee.c create mode 100644 include/linux/firmware/qcom/qcom_pas.h -- 2.51.0

3 days, 8 hours

3
21
0 0

[REPORT] tee: tee_ioctl_supp_recv() missing tee_shm_put() cleanup for memref params

by Qihang

Hi, I would like to report a likely shared-memory reference leak in drivers/tee/tee_core.c, in tee_ioctl_supp_recv(). The issue is that tee_ioctl_supp_recv() calls params_from_user(), which acquires references for MEMREF-type parameters via tee_shm_get_from_id(), but the cleanup path only frees the params array and does not drop the acquired shm references. Relevant code in tee_ioctl_supp_recv(): rc = params_from_user(ctx, params, num_params, uarg->params); if (rc) goto out; rc = ctx->teedev->desc->ops->supp_recv(ctx, &func, &num_params, params); if (rc) goto out; ... out: kfree(params); return rc; By contrast, other callers of params_from_user() in tee_core.c do release MEMREF references on cleanup, for example: - tee_ioctl_open_session() - tee_ioctl_invoke() - tee_ioctl_object_invoke() The helper comment in param_from_user_memref() also states that the caller is responsible for calling tee_shm_put() on all resolved pointers. Reachability / trigger paths: 1. qcomtee backend: qcomtee registers .supp_recv = qcomtee_supp_recv on a non-privileged tee device path. qcomtee_supp_recv() rejects any non-meta parameter after the first one: for (i = 1; i < *num_params; i++) if (params[i].attr) return -EINVAL; This allows a path where params_from_user() has already acquired a shm reference for a MEMREF parameter, then qcomtee_supp_recv() returns an error, and tee_ioctl_supp_recv() exits without tee_shm_put(). 2. Partial failure before backend callback: if params_from_user() successfully resolves an earlier MEMREF parameter and then fails on a later parameter, tee_ioctl_supp_recv() still goes to the same cleanup path without dropping already acquired shm refs. This means the issue is not just a backend-specific quirk: the core ioctl cleanup path itself is missing tee_shm_put() handling. Impact: - leaked shared-memory references - shared-memory objects may remain pinned and never reach final release - repeated triggering can cause resource exhaustion / DoS This does not appear to be a UAF, since refcount_t saturation prevents wraparound. The impact looks limited to resource leakage and availability. If useful, I can also prepare a patch. Thanks, Qihang

5 days, 9 hours

3
12
0 0

KLMBG4GEUF

by İsa Coşkun

Hello, I am working on embedded automotive systems repair and investigating behavior of Samsung eMMC (KLMBG4GEUF) in systems that appear to use OP-TEE for secure storage. Real scenario: - Two identical devices (same hardware) - One working, one not booting - Full eMMC dump taken from working device: - USER - BOOT1 / BOOT2 - EXT_CSD - RPMB (reported readable, but content appears empty or not usable) Tests: - Writing full dump to another device → no boot - Swapping eMMC between boards → both fail - Writing only USER → no change From observations: - RPMB appears non-clonable - Secure storage likely bound to hardware - Boot seems dependent on this binding Questions: 1. In OP-TEE, is RPMB always tied to a hardware unique key (HUK)? 2. Is it expected that RPMB content cannot be reused across identical devices? 3. Does OP-TEE enforce secure storage binding in a way that prevents cloning? 4. In case of damaged eMMC, is there any supported way to reinitialize or recover secure storage? I am not trying to bypass security, but to understand the architectural limitation in real repair scenarios. Any clarification would be highly appreciated. Best regards

1 week, 3 days

2
1
0 0

[PATCH v4 00/15] firmware: qcom: Add OP-TEE PAS service support

by Sumit Garg

From: Sumit Garg <sumit.garg(a)oss.qualcomm.com> Qcom platforms has the legacy of using non-standard SCM calls splintered over the various kernel drivers. These SCM calls aren't compliant with the standard SMC calling conventions which is a prerequisite to enable migration to the FF-A specifications from Arm. OP-TEE as an alternative trusted OS to Qualcomm TEE (QTEE) can't support these non-standard SCM calls. And even for newer architectures using S-EL2 with Hafnium support, QTEE won't be able to support SCM calls either with FF-A requirements coming in. And with both OP-TEE and QTEE drivers well integrated in the TEE subsystem, it makes further sense to reuse the TEE bus client drivers infrastructure. The added benefit of TEE bus infrastructure is that there is support for discoverable/enumerable services. With that client drivers don't have to manually invoke a special SCM call to know the service status. So enable the generic Peripheral Authentication Service (PAS) provided by the firmware. It acts as the common layer with different TZ backends plugged in whether it's an SCM implementation or a proper TEE bus based PAS service implementation. The TEE PAS service ABI is designed to be extensible with additional API as PTA_QCOM_PAS_CAPABILITIES. This allows to accommodate any future extensions of the PAS service needed while still maintaining backwards compatibility. Currently OP-TEE support is being added to provide the backend PAS service implementation which can be found as part of this PR [1]. This implementation has been tested on Kodiak/RB3Gen2 board with lemans EVK board being the next target. In addition to that WIN/IPQ targets planning to use OP-TEE will use this service too. Surely the backwards compatibility is maintained and tested for SCM backend. Note that kernel PAS service support while running in EL2 is at parity among OP-TEE vs QTEE. Especially the media (venus/iris) support depends on proper IOMMU support being worked out on the PAS client end. Patch summary: - Patch #1: adds Kodiak EL2 overlay since boot stack with TF-A/OP-TEE only allow UEFI and Linux to boot in EL2. - Patch #2: adds generic PAS service. - Patch #3: migrates SCM backend to generic PAS service. - Patch #4: adds TEE/OP-TEE backend for generic PAS service. - Patch #5-#13: migrates all client drivers to generic PAS service. - Patch #14: drops legacy PAS SCM exported APIs. The patch-set is based on v7.1-rc1 tag and can be found in git tree here [2]. Merge strategy: It is expected due to APIs dependency, the entire patch-set to go via the Qcom tree. All other subsystem maintainers, it will be great if I can get acks for the corresponding subsystem patches. [1] https://github.com/OP-TEE/optee_os/pull/7721 [2] https://git.kernel.org/pub/scm/linux/kernel/git/sumit.garg/linux.git/log/?h… --- Changes in v4: - Incorporate misc. comments on patch #4. - Picked up an ack for patch #10. - Clarify in cover letter about state of media support. Changes in v3: - Incorporated some style and misc. comments for patch #2, #3 and #4. - Add QCOM_PAS Kconfig dependency for various subsystems. - Switch from pseudo TA to proper TA invoke commands. Changes in v2: - Fixed kernel doc warnings. - Polish commit message and comments for patch #2. - Pass proper PAS ID in set_remote_state API for media firmware drivers. - Added Maintainer entry and dropped MODULE_AUTHOR. Mukesh Ojha (1): arm64: dts: qcom: kodiak: Add EL2 overlay Sumit Garg (14): firmware: qcom: Add a generic PAS service firmware: qcom_scm: Migrate to generic PAS service firmware: qcom: Add a PAS TEE service remoteproc: qcom_q6v5_pas: Switch over to generic PAS TZ APIs remoteproc: qcom_q6v5_mss: Switch to generic PAS TZ APIs soc: qcom: mdtloader: Switch to generic PAS TZ APIs remoteproc: qcom_wcnss: Switch to generic PAS TZ APIs remoteproc: qcom: Select QCOM_PAS generic service drm/msm: Switch to generic PAS TZ APIs media: qcom: Switch to generic PAS TZ APIs net: ipa: Switch to generic PAS TZ APIs wifi: ath12k: Switch to generic PAS TZ APIs firmware: qcom_scm: Remove SCM PAS wrappers MAINTAINERS: Add maintainer entry for Qualcomm PAS TZ service MAINTAINERS | 9 + arch/arm64/boot/dts/qcom/Makefile | 2 + arch/arm64/boot/dts/qcom/kodiak-el2.dtso | 35 ++ drivers/firmware/qcom/Kconfig | 19 + drivers/firmware/qcom/Makefile | 2 + drivers/firmware/qcom/qcom_pas.c | 288 +++++++++++ drivers/firmware/qcom/qcom_pas.h | 50 ++ drivers/firmware/qcom/qcom_pas_tee.c | 479 ++++++++++++++++++ drivers/firmware/qcom/qcom_scm.c | 302 ++++------- drivers/gpu/drm/msm/Kconfig | 1 + drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 4 +- drivers/gpu/drm/msm/adreno/adreno_gpu.c | 11 +- drivers/media/platform/qcom/iris/Kconfig | 25 +- .../media/platform/qcom/iris/iris_firmware.c | 9 +- drivers/media/platform/qcom/venus/Kconfig | 1 + drivers/media/platform/qcom/venus/firmware.c | 11 +- drivers/net/ipa/Kconfig | 2 +- drivers/net/ipa/ipa_main.c | 13 +- drivers/net/wireless/ath/ath12k/Kconfig | 2 +- drivers/net/wireless/ath/ath12k/ahb.c | 8 +- drivers/remoteproc/Kconfig | 1 + drivers/remoteproc/qcom_q6v5_mss.c | 5 +- drivers/remoteproc/qcom_q6v5_pas.c | 51 +- drivers/remoteproc/qcom_wcnss.c | 12 +- drivers/soc/qcom/mdt_loader.c | 12 +- include/linux/firmware/qcom/qcom_pas.h | 43 ++ include/linux/firmware/qcom/qcom_scm.h | 29 -- include/linux/soc/qcom/mdt_loader.h | 6 +- 28 files changed, 1115 insertions(+), 317 deletions(-) create mode 100644 arch/arm64/boot/dts/qcom/kodiak-el2.dtso create mode 100644 drivers/firmware/qcom/qcom_pas.c create mode 100644 drivers/firmware/qcom/qcom_pas.h create mode 100644 drivers/firmware/qcom/qcom_pas_tee.c create mode 100644 include/linux/firmware/qcom/qcom_pas.h -- 2.51.0

1 week, 5 days

4
44
0 0

[PATCH v11 00/11] 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 12/12] Documentation: tee: Add Qualcomm TEE driver. You can run basic tests with following steps: git clone https://github.com/quic/quic-teec.git cd quic-teec mkdir build cmake .. -DCMAKE_TOOLCHAIN_FILE=CMakeToolchain.txt -DBUILD_UNITTEST=ON https://github.com/quic/quic-teec/blob/main/README.md lists dependencies needed to build the above. More comprehensive tests are availabe at https://github.com/qualcomm/minkipc. root@qcom-armv8a:~# qtee_supplicant & root@qcom-armv8a:~# qtee_supplicant: process entry PPID = 378 Total listener services to start = 4 Opening CRequestTABuffer_open Path /data/ register_service ::Opening CRegisterTABufCBO_UID Calling TAbufCBO Register QTEE_SUPPLICANT RUNNING root@qcom-armv8a:~# smcinvoke_client -c /data 1 Run callback obj test... Load /data/tzecotestapp.mbn, size 52192, buf 0x1e44ba0. System Time: 2024-02-27 17:26:31 PASSED - Callback tests with Buffer inputs. PASSED - Callback tests with Remote and Callback object inputs. PASSED - Callback tests with Memory Object inputs. TEST PASSED! root@qcom-armv8a:~# root@qcom-armv8a:~# smcinvoke_client -m /data 1 Run memory obj test... Load /data/tzecotestapp.mbn, size 52192, buf 0x26cafba0. System Time: 2024-02-27 17:26:39 PASSED - Single Memory Object access Test. PASSED - Two Memory Object access Test. TEST PASSED! This series has been tested for QTEE object invocations, including loading a TA, requesting services from the TA, memory sharing, and handling callback requests to a supplicant. Tested platforms: sm8650-mtp, sm8550-qrd, sm8650-qrd, sm8650-hdk [1] https://www.kernel.org/doc/Documentation/tee.txt Signed-off-by: Amirreza Zarrabi <amirreza.zarrabi(a)oss.qualcomm.com> Changes in v11: - Rebased on next. - Link to v10: https://lore.kernel.org/r/20250909-qcom-tee-using-tee-ss-without-mem-obj-v1… Changes in v10: - Remove all loggings in qcom_scm_qtee_init(). - Reorder patches. - Link to v9: https://lore.kernel.org/r/20250901-qcom-tee-using-tee-ss-without-mem-obj-v9… Changes in v9: - Remove unnecessary logging in qcom_scm_probe(). - Replace the platform_device_alloc()/add() sequence with platform_device_register_data(). - Fixed sparse warning. - Fixed documentation typo. - Link to v8: https://lore.kernel.org/r/20250820-qcom-tee-using-tee-ss-without-mem-obj-v8… Changes in v8: - Check if arguments to qcom_scm_qtee_invoke_smc() and qcom_scm_qtee_callback_response() are NULL. - Add CPU_BIG_ENDIAN as a dependency to Kconfig. - Fixed kernel bot errors. - Link to v7: https://lore.kernel.org/r/20250812-qcom-tee-using-tee-ss-without-mem-obj-v7… Changes in v7: - Updated copyrights. - Updated Acked-by: tags. - Fixed kernel bot errors. - Link to v6: https://lore.kernel.org/r/20250713-qcom-tee-using-tee-ss-without-mem-obj-v6… Changes in v6: - Relocate QTEE version into the driver's main service structure. - Simplfies qcomtee_objref_to_arg() and qcomtee_objref_from_arg(). - Enhanced the return logic of qcomtee_object_do_invoke_internal(). - Improve comments and remove redundant checks. - Improve helpers in qcomtee_msh.h to use GENMASK() and FIELD_GET(). - updated Tested-by:, Acked-by:, and Reviewed-by: tags - Link to v5: https://lore.kernel.org/r/20250526-qcom-tee-using-tee-ss-without-mem-obj-v5… Changes in v5: - Remove references to kernel services and public APIs. - Support auto detection for failing devices (e.g., RB1, RB4). - Add helpers for obtaining client environment and service objects. - Query the QTEE version and print it. - Move remaining static variables, including the object table, to struct qcomtee. - Update TEE_MAX_ARG_SIZE to 4096. - Add a dependancy to QCOM_TZMEM_MODE_SHMBRIDGE in Kconfig - Reorganize code by removing release.c and qcom_scm.c. - Add more error messages and improve comments. - updated Tested-by:, Acked-by:, and Reviewed-by: tags - Link to v4: https://lore.kernel.org/r/20250428-qcom-tee-using-tee-ss-without-mem-obj-v4… Changes in v4: - Move teedev_ctx_get/put and tee_device_get/put to tee_core.h. - Rename object to id in struct tee_ioctl_object_invoke_arg. - Replace spinlock with mutex for qtee_objects_idr. - Move qcomtee_object_get to qcomtee_user/memobj_param_to_object. - More code cleanup following the comments. - Cleanup documentations. - Update MAINTAINERS file. - Link to v3: https://lore.kernel.org/r/20250327-qcom-tee-using-tee-ss-without-mem-obj-v3… Changes in v3: - Export shm_bridge create/delete APIs. - Enable support for QTEE memory objects. - Update the memory management code to use the TEE subsystem for all allocations using the pool. - Move all driver states into the driver's main service struct. - Add more documentations. - Link to v2: https://lore.kernel.org/r/20250202-qcom-tee-using-tee-ss-without-mem-obj-v2… Changes in v2: - Clean up commit messages and comments. - Use better names such as ubuf instead of membuf or QCOMTEE prefix instead of QCOM_TEE, or names that are more consistent with other TEE-backend drivers such as qcomtee_context_data instead of qcom_tee_context. - Drop the DTS patch and instantiate the device from the scm driver. - Use a single structure for all driver's internal states. - Drop srcu primitives and use the existing mutex for synchronization between the supplicant and QTEE. - Directly use tee_context to track the lifetime of qcomtee_context_data. - Add close_context() to be called when the user closes the tee_context. - Link to v1: https://lore.kernel.org/r/20241202-qcom-tee-using-tee-ss-without-mem-obj-v1… Changes in v1: - It is a complete rewrite to utilize the TEE subsystem. - Link to RFC: https://lore.kernel.org/all/20240702-qcom-tee-object-and-ioctls-v1-0-633c3d… --- Amirreza Zarrabi (11): firmware: qcom: tzmem: export shm_bridge create/delete firmware: qcom: scm: add support for object invocation tee: allow a driver to allocate a tee_device without a pool tee: add close_context to TEE driver operation tee: add TEE_IOCTL_PARAM_ATTR_TYPE_UBUF tee: add TEE_IOCTL_PARAM_ATTR_TYPE_OBJREF tee: increase TEE_MAX_ARG_SIZE to 4096 tee: add Qualcomm TEE driver tee: qcom: add primordial object tee: qcom: enable TEE_IOC_SHM_ALLOC ioctl Documentation: tee: Add Qualcomm TEE driver Documentation/tee/index.rst | 1 + Documentation/tee/qtee.rst | 96 ++++ MAINTAINERS | 7 + drivers/firmware/qcom/qcom_scm.c | 119 ++++ drivers/firmware/qcom/qcom_scm.h | 7 + drivers/firmware/qcom/qcom_tzmem.c | 63 ++- drivers/tee/Kconfig | 1 + drivers/tee/Makefile | 1 + drivers/tee/qcomtee/Kconfig | 12 + drivers/tee/qcomtee/Makefile | 9 + drivers/tee/qcomtee/async.c | 182 ++++++ drivers/tee/qcomtee/call.c | 820 +++++++++++++++++++++++++++ drivers/tee/qcomtee/core.c | 915 +++++++++++++++++++++++++++++++ drivers/tee/qcomtee/mem_obj.c | 169 ++++++ drivers/tee/qcomtee/primordial_obj.c | 113 ++++ drivers/tee/qcomtee/qcomtee.h | 185 +++++++ drivers/tee/qcomtee/qcomtee_msg.h | 304 ++++++++++ drivers/tee/qcomtee/qcomtee_object.h | 316 +++++++++++ drivers/tee/qcomtee/shm.c | 150 +++++ drivers/tee/qcomtee/user_obj.c | 692 +++++++++++++++++++++++ drivers/tee/tee_core.c | 127 ++++- drivers/tee/tee_private.h | 6 - include/linux/firmware/qcom/qcom_scm.h | 6 + include/linux/firmware/qcom/qcom_tzmem.h | 15 + include/linux/tee_core.h | 54 +- include/linux/tee_drv.h | 12 + include/uapi/linux/tee.h | 56 +- 27 files changed, 4410 insertions(+), 28 deletions(-) --- base-commit: 8b8aefa5a5c7d4a65883e5653cf12f94c0b68dbf change-id: 20241202-qcom-tee-using-tee-ss-without-mem-obj-362c66340527 Best regards, -- Amirreza Zarrabi <amirreza.zarrabi(a)oss.qualcomm.com>

1 week, 5 days

3
15
0 0

KLMBG4GEUF

by İsa Coşkun

Hello, I am working on embedded automotive systems repair and investigating behavior of Samsung eMMC (KLMBG4GEUF) in systems that appear to use OP-TEE for secure storage. Real scenario: - Two identical devices (same hardware) - One working, one not booting - Full eMMC dump taken from working device: - USER - BOOT1 / BOOT2 - EXT_CSD - RPMB (reported readable, but content appears empty or not usable) Tests: - Writing full dump to another device → no boot - Swapping eMMC between boards → both fail - Writing only USER → no change From observations: - RPMB appears non-clonable - Secure storage likely bound to hardware - Boot seems dependent on this binding Questions: 1. In OP-TEE, is RPMB always tied to a hardware unique key (HUK)? 2. Is it expected that RPMB content cannot be reused across identical devices? 3. Does OP-TEE enforce secure storage binding in a way that prevents cloning? 4. In case of damaged eMMC, is there any supported way to reinitialize or recover secure storage? I am not trying to bypass security, but to understand the architectural limitation in real repair scenarios. Any clarification would be highly appreciated. Best regards,

1 week, 6 days

1
0
0 0

[PATCH] tee: optee: Allow MT_NORMAL_TAGGED shared memory

by Hirokazu Honda

From: Hirokazu Honda <hiroh(a)chromium.org> On ARM64, shared memory can have MT_NORMAL_TAGGED attribute when using the Memory Tagging Extension (MTE). The OP-TEE driver needs to recognize this as normal memory to allow sharing such buffers with the Secure World. Signed-off-by: Hirokazu Honda <hiroh(a)chromium.org> --- drivers/tee/optee/call.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c index 9effe88049e9..e046aff61828 100644 --- a/drivers/tee/optee/call.c +++ b/drivers/tee/optee/call.c @@ -602,7 +602,8 @@ static bool is_normal_memory(pgprot_t p) return (((pgprot_val(p) & L_PTE_MT_MASK) == L_PTE_MT_WRITEALLOC) || ((pgprot_val(p) & L_PTE_MT_MASK) == L_PTE_MT_WRITEBACK)); #elif defined(CONFIG_ARM64) - return (pgprot_val(p) & PTE_ATTRINDX_MASK) == PTE_ATTRINDX(MT_NORMAL); + return ((pgprot_val(p) & PTE_ATTRINDX_MASK) == PTE_ATTRINDX(MT_NORMAL)) || + ((pgprot_val(p) & PTE_ATTRINDX_MASK) == PTE_ATTRINDX(MT_NORMAL_TAGGED)); #else #error "Unsupported architecture" #endif -- 2.54.0.rc1.513.gad8abe7a5a-goog

2 weeks, 4 days

3
3
0 0

2026

2025

2024

2023

2022

2021

2020

OP-TEE