- OP-TEE - lists.trustedfirmware.org

[PATCH v2 0/6] Add TEE based client driver for UEFI Secure Application

by Harshal Dev

On Qualcomm SoC based platforms, UEFI stores EFI variables within the Replay Protected Memory Block (RPMB) which is only accessible by the Qualcomm Trusted Execution Environment (QTEE). For Qualcomm platforms without emulated RPMB support, specifically platforms where RPMB is not located within SPI-NOR storage and instead located on UFS/EMMC storage, non-volatile EFI variables can only be set via a callback request from the UEFI Secure Application to the RPMB service running in user-space (within the QTEE supplicant [1]). Unlike the QCOM-TEE driver, the QSEECOM driver (used by the current QSEECOM based uefisecapp) does not support callback requests. And on certain Qualcomm platforms such as the RB3Gen2, attempts to access the QSEECOM interface fail due to lack of support within Qualcomm TEE. On these platforms, a TEE based uefisecapp client driver is required to: 1. Access cached & volatile EFI variables stored in uefisecapp's memory. 2. Ensure persistence of non-volatile EFI variables via writes through the RPMB service hosted in the QTEE supplicant. This series introduces such a uefisecapp TEE client driver for the aforementioned Qualcomm platforms which installs efi-var operations _if_ the QCOMTEE driver registers support for an object-IPC based uefisecapp service on the TEE bus during its probe. Only new QTEE firmware versions available at [2] provide this support. Thus, QCOMTEE now maintains a static list of always-available object-IPC based secure services exposed by QTEE. These services are implemented either within the QTEE kernel or within a pre-loaded Trusted Application (TA) usually loaded by the bootloader. The uefisecapp TA is an example of a preloaded TA loaded by UEFI. A static list is required since QTEE does not yet expose any way to dynamically query and enumerate the services exposed by it. To facilitate object-IPC interactions from the kernel-space, this series also introduces a tee_client_object_invoke_func() to allow invocation of TEE objects similar to the existing tee_client_invoke_func() API exported by the TEE subsystem which allows invocation of TEE functions. Some suporting changes are also introduced to track and handle operations for TEE contexts opened from the kernel-space in the back-end QCOM-TEE driver. Finally and as previously mentioned, access to the object-IPC based uefisecapp service is restricted on older QTEE firmware versions. A new QTEE firmware release must be picked up from QArtifactory [2] for all upstream supported Qualcomm SoCs to enable access to uefisecapp service via the TEE client driver. This patch series has been validated on Kodiak RB3Gen2 platform with UFS storage by attempting to read/write EFI variables via the efivar tool [3] after mounting the efivarfs filesystem. See [4] for an example. Merge Strategy: This patch series could either be taken from the OP-TEE tree or the QCOM soc tree. I would prefer it to be picked by the OP-TEE tree since all except the uefisecapp TEE client driver patch in this series make changes relevant to the TEE subsystem. It would be great if the QCOM soc tree maintainers can Ack the uefisecapp driver patch. [1] https://github.com/qualcomm/minkipc [2] https://shorturl.at/zQU07 [3] https://github.com/rhboot/efivar [4] https://docs.qualcomm.com/doc/80-70020-27/topic/manage_uefi_environment_var… Signed-off-by: Harshal Dev <harshal.dev(a)oss.qualcomm.com> --- Changes in v2: - Drop using MSB of the object_id to distingush kernel and user object invoke contexts. - Introduce enum tee_object_invoke_origin to check the context of object invocation. - Link to v1: https://lore.kernel.org/r/20260707-qcom_uefisecapp_migrate_qcomtee-v1-0-f65… --- Amirreza Zarrabi (2): tee: Add kernel client object invoke helper tee: qcomtee: Allow object invokes from kernel clients Harshal Dev (4): tee: qcomtee: Track the object invocation context tee: Export uuidv5 generation for TEE backends tee: qcomtee: Add support for registering QTEE services on TEE bus firmware: qcom: Add support for TEE based EFI-var client driver MAINTAINERS | 7 + drivers/firmware/qcom/Kconfig | 24 ++ drivers/firmware/qcom/Makefile | 1 + drivers/firmware/qcom/qcom_tee_uefisecapp.c | 525 ++++++++++++++++++++++++++++ drivers/firmware/qcom/qcom_tee_uefisecapp.h | 120 +++++++ drivers/tee/qcomtee/call.c | 205 ++++++++++- drivers/tee/qcomtee/core.c | 9 +- drivers/tee/qcomtee/qcomtee.h | 12 + drivers/tee/qcomtee/qcomtee_msg.h | 1 + drivers/tee/qcomtee/qcomtee_object.h | 16 +- drivers/tee/tee_core.c | 24 +- include/linux/tee_core.h | 23 +- include/linux/tee_drv.h | 18 +- 13 files changed, 952 insertions(+), 33 deletions(-) --- base-commit: f3e6330d7fe42b204af05a2dbc68b379e0ad179e change-id: 20260408-qcom_uefisecapp_migrate_qcomtee-13869d45e014 Best regards, -- Harshal Dev <harshal.dev(a)oss.qualcomm.com>

4 hours, 29 minutes

2
9
0 0

[PATCH v9 00/14] 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 and lemans EVK boards. In addition to that WIN/IPQ targets tested OP-TEE with 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 generic PAS service. - Patch #2: migrates SCM backend to generic PAS service. - Patch #3: adds TEE/OP-TEE backend for generic PAS service. - Patch #4-#12: migrates all client drivers to generic PAS service. - Patch #13: drops legacy PAS SCM exported APIs. The patch-set is based on v7.2-rc1 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 v9: - Rebased to 7.2-rc1. - Enable SCM backend similar to TEE if ARCH_QCOM is set. - Address misc. comments from Konrad. - Add checks for corner cases (although not reachable as per OP-TEE ABI) reported by Shashiko on patch #3. - Picked up review tags from Konrad. Changes in v8: - Rebased on mainline tip (no functional changes). - Now Lemans EVK is also tested to support OP-TEE PAS here: https://github.com/OP-TEE/optee_os/pull/7845 - Drop Kodiak DT patch as it is carried independently by Mukesh here: https://lore.kernel.org/lkml/20260624063952.2242702-1-mukesh.ojha@oss.qualc… - Regarding Sashiko comments, I have already replied in v6 the ones that don't apply but in v7 I got the same comments again. Specific context reasoning which Shashiko ignores: - ABI contract between Linux and TZ - No support for multiple concurrent backends - The TZ backend doesn’t detach during the entire boot cycle Changes in v7: - Rebased to qcom tree (for-next branch) tip. - Merged patch #5 and #7 due to build dependency. - Disabled modem for kodiak EL2 as it isn't tested yet. - Fix an issue found out by sashiko-bot for patch #4. Changes in v6: - Rebased to v7.1-rc4 tag. - Patch #14: fixed ret error print. - Add Kconfig descriptions for PAS symbols such that they are visible in menuconfig to update. 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. 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 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 + drivers/firmware/qcom/Kconfig | 22 +- drivers/firmware/qcom/Makefile | 2 + drivers/firmware/qcom/qcom_pas.c | 299 +++++++++++ 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 | 27 +- .../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 | 10 +- 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 +- 26 files changed, 1095 insertions(+), 321 deletions(-) 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.53.0

1 day, 2 hours

6
30
0 0

[PATCH 0/6] Add TEE based client driver for UEFI Secure Application

by Harshal Dev

On Qualcomm SoC based platforms, UEFI stores EFI variables within the Replay Protected Memory Block (RPMB) which is only accessible by the Qualcomm Trusted Execution Environment (QTEE). For Qualcomm platforms without emulated RPMB support, specifically platforms where RPMB is not located within SPI-NOR storage and instead located on UFS/EMMC storage, non-volatile EFI variables can only be set via a callback request from the UEFI Secure Application to the RPMB service running in user-space (within the QTEE supplicant [1]). Unlike the QCOM-TEE driver, the QSEECOM driver (used by the current QSEECOM based uefisecapp) does not support callback requests. And on certain Qualcomm platforms such as the RB3Gen2, attempts to access the QSEECOM interface fail due to lack of support within Qualcomm TEE. On these platforms, a TEE based uefisecapp client driver is required to: 1. Access cached & volatile EFI variables stored in uefisecapp's memory. 2. Ensure persistence of non-volatile EFI variables via writes through the RPMB service hosted in the QTEE supplicant. This series introduces such a uefisecapp TEE client driver for the aforementioned Qualcomm platforms which installs efi-var operations _if_ the QCOMTEE driver registers support for an object-IPC based uefisecapp service on the TEE bus during its probe. Only new QTEE firmware versions available at [2] provide this support. Thus, QCOMTEE now maintains a static list of always-available object-IPC based secure services exposed by QTEE. These services are implemented either within the QTEE kernel or within a pre-loaded Trusted Application (TA) usually loaded by the bootloader. The uefisecapp TA is an example of a preloaded TA loaded by UEFI. A static list is required since QTEE does not yet expose any way to dynamically query and enumerate the services exposed by it. To facilitate object-IPC interactions from the kernel-space, this series also introduces a tee_client_object_invoke_func() to allow invocation of TEE objects similar to the existing tee_client_invoke_func() API exported by the TEE subsystem which allows invocation of TEE functions. Some suporting changes are also introduced to track and handle operations for TEE contexts opened from the kernel-space in the back-end QCOM-TEE driver along with associated changes in user-space libqcomtee via Pull Request [3]. Finally and as previously mentioned, access to the object-IPC based uefisecapp service is restricted on older QTEE firmware versions. A new QTEE firmware release must be picked up from QArtifactory [2] for all upstream supported Qualcomm SoCs to enable access to uefisecapp service via the TEE client driver. This patch series has been validated on Kodiak RB3Gen2 platform with UFS storage by attempting to read/write EFI variables via the efivar tool [4] after mounting the efivarfs filesystem. See [5] for an example. Merge Strategy: This patch series could either be taken from the OP-TEE tree or the QCOM soc tree. I would prefer it to be picked by the OP-TEE tree since all except the uefisecapp TEE client driver patch in this series make changes relevant to the TEE subsystem. It would be great if the QCOM soc tree maintainers can Ack the uefisecapp driver patch. [1] https://github.com/qualcomm/minkipc [2] https://shorturl.at/zQU07 [3] https://github.com/quic/quic-teec/pull/27 [4] https://github.com/rhboot/efivar [5] https://docs.qualcomm.com/doc/80-70020-27/topic/manage_uefi_environment_var… Signed-off-by: Harshal Dev <harshal.dev(a)oss.qualcomm.com> --- Amirreza Zarrabi (2): tee: Add kernel client object invoke helper tee: qcomtee: Allow object invokes from kernel clients Harshal Dev (4): tee: qcomtee: Track the object invocation context tee: Export uuidv5 generation for TEE clients tee: qcomtee: Add support for registering QTEE services on TEE bus firmware: qcom: Add support for TEE based EFI-var client driver MAINTAINERS | 7 + drivers/firmware/qcom/Kconfig | 24 ++ drivers/firmware/qcom/Makefile | 1 + drivers/firmware/qcom/qcom_tee_uefisecapp.c | 525 ++++++++++++++++++++++++++++ drivers/firmware/qcom/qcom_tee_uefisecapp.h | 120 +++++++ drivers/tee/qcomtee/call.c | 218 +++++++++++- drivers/tee/qcomtee/core.c | 9 +- drivers/tee/qcomtee/qcomtee.h | 18 + drivers/tee/qcomtee/qcomtee_msg.h | 1 + drivers/tee/qcomtee/qcomtee_object.h | 16 +- drivers/tee/tee_core.c | 26 +- include/linux/tee_core.h | 15 + include/linux/tee_drv.h | 18 +- 13 files changed, 968 insertions(+), 30 deletions(-) --- base-commit: f3e6330d7fe42b204af05a2dbc68b379e0ad179e change-id: 20260408-qcom_uefisecapp_migrate_qcomtee-13869d45e014 Best regards, -- Harshal Dev <harshal.dev(a)oss.qualcomm.com>

2 days, 2 hours

3
14
0 0

Re: [PATCH] tee: remove dead select from kconfig

by Arnd Bergmann

On Wed, Jul 15, 2026, at 11:25, Julian Braha wrote: > 'select' does not work on config options in a 'choice', so currently it is > possible to enable QCOMTEE without QCOM_TZMEM_MODE_SHMBRIDGE. > > This patch removes the select. > > I've compile-tested this and found that it builds fine without > QCOM_TZMEM_MODE_SHMBRIDGE, but I don't have the hardware to runtime test. > Please advise if it would be better to make QCOM_TZMEM_MODE_SHMBRIDGE a > dependency. > > This dead select was found by kconfirm, a static analysis tool for Kconfig. Right, clearly something is wrong here. > @@ -5,7 +5,6 @@ config QCOMTEE > depends on ARCH_QCOM || COMPILE_TEST > depends on !CPU_BIG_ENDIAN > select QCOM_SCM > - select QCOM_TZMEM_MODE_SHMBRIDGE > help From the implementation, my guess would be that QCOMTEE actually requires QCOM_TZMEM_MODE_SHMBRIDGE and it only links successfully because of the stub helpers added in 8aa1e3a6f0ff ("firmware: qcom: tzmem: export shm_bridge create/delete"). If that is the case, we probably need a 'depends on QCOM_TZMEM_MODE_SHMBRIDGE' here, and can remove the stub functions. It is also possible that the 'choice' itself is wrong, and this should be detected at runtime. It is a rather odd Kconfig option, as it sounds like only one of the two is correct on a given hardware. The CONFIG_QCOM_TZMEM_MODE_SHMBRIDGE variant contains runtime hardware detection, so it should actually be safe to enable that anywhere. If this is true, we could just turn the choice into a 'bool' symbol and remove the generic case. I've added a few more people to Cc that may know the correct answer here. Arnd

2 days, 7 hours

2
1
0 0

[PATCH v1 0/2] ufs: rpmb: make RPMB usable with OP-TEE key derivation

by Jorge Ramirez-Ortiz

This series makes UFS RPMB work out of the box with an OP-TEE that implements the standard eMMC RPMB key-derivation flow, without requiring any fundamental changes on the OP-TEE side. RPMB provides an authenticated, replay-protected storage area whose security relies on a secret authentication key. In our setup that key is never exposed to the kernel: OP-TEE derives it in the secure world from its hardware-unique key and a device identifier (dev_id) that the RPMB core hands down. OP-TEE's implementation targets eMMC, where dev_id is the 16-byte eMMC CID, and both the fixed length and the raw-CID layout are baked into its key derivation. Two things stand in the way of reusing that same, unmodified OP-TEE flow for UFS RPMB: 1. On a cold boot the very first frame sent to the RPMB well-known LU comes back with a power-on UNIT ATTENTION (ASC 0x29), which the SCSI core reports rather than retries. RPMB has no earlier guaranteed access that could clear the condition first, so RPMB fails on every power cycle. Patch 1 asks the SCSI core to retry the power-on UNIT ATTENTION on the RPMB WLUN. 2. The UFS RPMB id is "<device_id>-R<region>", which is variable length and longer than 16 bytes. Passing it verbatim would tie the derived key to a length OP-TEE does not expect and diverge from the fixed eMMC CID ABI. Patch 2 hashes it into a fixed 16-byte dev_id with blake2s, keeping the key stable and unique per region while matching the eMMC CID layout OP-TEE relies on. The hash algorithm and input string are thus part of the key-derivation ABI and must stay stable. With both patches, UFS RPMB is functional from the first access after a cold boot and derives keys through the existing eMMC-style OP-TEE flow, (requires minimal OP-TEE changes pending on the CID proposal done here). Tested on IQ-9075 with Open Firmware [1], pending OP-TEE changes [1]https://ldts.github.io/qcom-buildroot v1: * ufs: rpmb: retry power-on UNIT ATTENTION on the RPMB WLUN: - fix using uses SCMD_FAILURE_ASC_ANY to retry any Unit Attention - fix unused variable * ufs: rpmb: use a fixed-length RPMB dev_id - fix selecting a non-existent Kconfig symbol Jorge Ramirez-Ortiz (2): ufs: rpmb: retry power-on UNIT ATTENTION on the RPMB WLUN ufs: rpmb: use a fixed-length RPMB dev_id drivers/ufs/core/ufs-rpmb.c | 39 ++++++++++++++++++++++++++++++++++--- 1 file changed, 36 insertions(+), 3 deletions(-) -- 2.54.0

5 days, 2 hours

3
4
0 0

ufs: rpmb: make RPMB usable with OP-TEE key derivation

by Jorge Ramirez-Ortiz

This series makes UFS RPMB work out of the box with an OP-TEE that implements the standard eMMC RPMB key-derivation flow, without requiring any fundamental changes on the OP-TEE side. RPMB provides an authenticated, replay-protected storage area whose security relies on a secret authentication key. In our setup that key is never exposed to the kernel: OP-TEE derives it in the secure world from its hardware-unique key and a device identifier (dev_id) that the RPMB core hands down. OP-TEE's implementation targets eMMC, where dev_id is the 16-byte eMMC CID, and both the fixed length and the raw-CID layout are baked into its key derivation. Two things stand in the way of reusing that same, unmodified OP-TEE flow for UFS RPMB: 1. On a cold boot the very first frame sent to the RPMB well-known LU comes back with a power-on UNIT ATTENTION (ASC 0x29), which the SCSI core reports rather than retries. RPMB has no earlier guaranteed access that could clear the condition first, so RPMB fails on every power cycle. Patch 1 asks the SCSI core to retry the power-on UNIT ATTENTION on the RPMB WLUN. 2. The UFS RPMB id is "<device_id>-R<region>", which is variable length and longer than 16 bytes. Passing it verbatim would tie the derived key to a length OP-TEE does not expect and diverge from the fixed eMMC CID ABI. Patch 2 hashes it into a fixed 16-byte dev_id with blake2s, keeping the key stable and unique per region while matching the eMMC CID layout OP-TEE relies on. The hash algorithm and input string are thus part of the key-derivation ABI and must stay stable. With both patches, UFS RPMB is functional from the first access after a cold boot and derives keys through the existing eMMC-style OP-TEE flow, (requires minimal OP-TEE changes). Jorge Ramirez-Ortiz (2): ufs: rpmb: retry power-on UNIT ATTENTION on the RPMB WLUN ufs: rpmb: use a fixed-length RPMB dev_id drivers/ufs/Kconfig | 1 + drivers/ufs/core/ufs-rpmb.c | 41 ++++++++++++++++++++++++++++++++++--- 2 files changed, 39 insertions(+), 3 deletions(-)

6 days, 15 hours

1
2
0 0

Re: OP-TEE Bug Bounty

by Arm PSIRT

Hi op-tee team, As part of the Arm bug bounty, we’ve recently sent a few messages to op-tee-security. Unfortunately we haven’t had any responses since Jens left Linaro. Please could we ask who remains on this list so that we can reach out to them directly? Many thanks, Arm PSIRT

1 week, 2 days

1
0
0 0

Re: [PATCH] Documentation: Extend the real-time hardware bits with some firmware bits

by Ilias Apalodimas

On Fri, 10 Jul 2026 at 10:31, Sebastian Andrzej Siewior <bigeasy(a)linutronix.de> wrote: > > On 2026-07-10 09:29:55 [+0300], Ilias Apalodimas wrote: > > Hi Sebastian! > Hi Ilias, > > > > +++ b/Documentation/core-api/real-time/hardware.rst > > > @@ -130,3 +130,95 @@ https://github.com/Linutronix/RTC-Testbench. > > > > [...] > > > > > + > > > +OP-TEE (ARM) > > > +~~~~~~~~~~~~ > > > > That's RISC-V as well nowadays > > I did not find much here. Their architecture isn't the same as on ARM is > it? But the overall concept is the same, right? I haven't checked the IRQ vectors on risc-v, but I assume they have a similar logic since that's an OP-TEE design decision not a per architecture one. > > > > + > > > +OP‑TEE uses a global serialization mechanism (the "big lock"), ensuring that on > > > +each core only one OP‑TEE thread executes secure‑world code at a time. > > > + > > > +Execution flows from the normal world (Linux) into the secure world (OP‑TEE) > > > +through the secure monitor at EL3. Linux and OP‑TEE cannot disable or mask each > > > +other’s interrupts because both run at EL1 in different security states. > > > > That's not always true. It depends on a combination of OP-TEE and TF-A > > configs iirc. > > The most common though is that IRQs and FIQs are directly delivered to > > S-EL1, in which case OP-TEE can mask IRQs. > > There's also a difference between GICv2 and GICv3 in the way > > interrupts are delivered. > > You are saying that OP-TEE can mask Linux' interrupts or if OP-TEE > instructs TF-A to do so (via config)? OP-TEE can mask Linux IRQs > > > > + > > > +Architecturally, the secure monitor can mask or reroute normal‑world interrupts > > > +before entering the secure world. In a correct OP‑TEE/ TF‑A implementation, it > > > +does not do this for the duration of secure calls. Normal‑world interrupts > > > +remain deliverable, and a normal‑world IRQ will preempt OP‑TEE via EL3 and > > > +return control to Linux. > > > > The 'sane' case is indeed where IRQs are delivered to OP-TEE which > > exits back to Linux immediately. > > > > > + > > > +Secure‑world interrupts (FIQs) are possible if the SoC routes a device's > > > +interrupt as secure. Such a secure FIQ will preempt Linux immediately, trap > > > +into EL3, and transfer control to OP‑TEE's secure interrupt handler. Linux > > > +cannot mask or preempt this. Secure FIQ handlers must therefore be extremely > > > +short to avoid introducing noticeable latency. > > > > There are also 'fast SMCs', which run with IRQs disabled for their > > entire duration. > > can their be distinguished somehow from normal SMC invocations or is > just a consequence that the secure monitor does not enable interrupts > during transition for some of the "functions"? They can be identified. There's a function identifier defined in the SMC calling conventions doc [0]. Bit 31 is always 1 for fast calls and 0 for yielding. > > > > + > > > +The transition from normal world -> secure monitor -> OP‑TEE and back introduces > > > +additional latency due to world switching and context save/ restore. This > > > +overhead is typically a few microseconds and usually remains in the noise > > > +floor. > > > > That's correct. > > > > > + > > > +If the secure monitor masks normal‑world interrupts during OP‑TEE invocations, > > > +or if OP‑TEE uses long‑running secure FIQ handlers, then OP‑TEE can introduce > > > +measurable latency spikes. > > > -- > > > 2.53.0 > > > > > > > Overall I think this is worth documenting, but infortunately there's a > > wider range of configs and corner cases we have to describe. > > Okay. [0] https://developer.arm.com/documentation/den0028/h/?lang=en Cheers /Ilias > > > Cheers > > /Ilias > > Sebastian

1 week, 5 days

2
1
0 0

Re: [PATCH] Documentation: Extend the real-time hardware bits with some firmware bits

by Ilias Apalodimas

Hi Sebastian! I'll let Jens fill in the gaps. Some general comments below. On Wed, 1 Jul 2026 at 12:12, Sebastian Andrzej Siewior <bigeasy(a)linutronix.de> wrote: > > I have been reviewing how OP‑TEE is implemented and how secure‑world > invocations behave. The goal was to determine whether an OP‑TEE call can > delay the Linux side and introduce latency depending on the time spent > in the secure world. > > Similar latency effects are already known for EFI runtime services, but > this was not documented. To mitigate the impact, EFI runtime invocations > can be restricted to specific CPUs so that real‑time workloads on other > CPUs remain unaffected. This mechanism, however, is only described in > the commit that introduced it. > > This change adds a firmware section that documents these behaviours > explicitly. It highlights cases where firmware can delay the kernel, > information that may be unfamiliar to some users and surprising-or > concerning-to others. > > Assisted-by: Microsoft-Copilot > Signed-off-by: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de> > --- > > I would appreciate an ACK from the OP-TEE camp that I got my little > research right. > > Documentation/core-api/real-time/hardware.rst | 92 +++++++++++++++++++ > 1 file changed, 92 insertions(+) > > diff --git a/Documentation/core-api/real-time/hardware.rst b/Documentation/core-api/real-time/hardware.rst > index 19f9bb3786e03..fb113848c2f70 100644 > --- a/Documentation/core-api/real-time/hardware.rst > +++ b/Documentation/core-api/real-time/hardware.rst > @@ -130,3 +130,95 @@ https://github.com/Linutronix/RTC-Testbench. [...] > + > +OP-TEE (ARM) > +~~~~~~~~~~~~ That's RISC-V as well nowadays > + > +OP‑TEE uses a global serialization mechanism (the "big lock"), ensuring that on > +each core only one OP‑TEE thread executes secure‑world code at a time. > + > +Execution flows from the normal world (Linux) into the secure world (OP‑TEE) > +through the secure monitor at EL3. Linux and OP‑TEE cannot disable or mask each > +other’s interrupts because both run at EL1 in different security states. That's not always true. It depends on a combination of OP-TEE and TF-A configs iirc. The most common though is that IRQs and FIQs are directly delivered to S-EL1, in which case OP-TEE can mask IRQs. There's also a difference between GICv2 and GICv3 in the way interrupts are delivered. > + > +Architecturally, the secure monitor can mask or reroute normal‑world interrupts > +before entering the secure world. In a correct OP‑TEE/ TF‑A implementation, it > +does not do this for the duration of secure calls. Normal‑world interrupts > +remain deliverable, and a normal‑world IRQ will preempt OP‑TEE via EL3 and > +return control to Linux. The 'sane' case is indeed where IRQs are delivered to OP-TEE which exits back to Linux immediately. > + > +Secure‑world interrupts (FIQs) are possible if the SoC routes a device's > +interrupt as secure. Such a secure FIQ will preempt Linux immediately, trap > +into EL3, and transfer control to OP‑TEE's secure interrupt handler. Linux > +cannot mask or preempt this. Secure FIQ handlers must therefore be extremely > +short to avoid introducing noticeable latency. There are also 'fast SMCs', which run with IRQs disabled for their entire duration. > + > +The transition from normal world -> secure monitor -> OP‑TEE and back introduces > +additional latency due to world switching and context save/ restore. This > +overhead is typically a few microseconds and usually remains in the noise > +floor. That's correct. > + > +If the secure monitor masks normal‑world interrupts during OP‑TEE invocations, > +or if OP‑TEE uses long‑running secure FIQ handlers, then OP‑TEE can introduce > +measurable latency spikes. > -- > 2.53.0 > Overall I think this is worth documenting, but infortunately there's a wider range of configs and corner cases we have to describe. Cheers /Ilias

1 week, 5 days

1
0
0 0

Re: [PATCH] Documentation: Extend the real-time hardware bits with some firmware bits

by Ilias Apalodimas

++Cc Jens on his kernel.org email On Wed, 1 Jul 2026 at 12:12, Sebastian Andrzej Siewior <bigeasy(a)linutronix.de> wrote: > > I have been reviewing how OP‑TEE is implemented and how secure‑world > invocations behave. The goal was to determine whether an OP‑TEE call can > delay the Linux side and introduce latency depending on the time spent > in the secure world. > > Similar latency effects are already known for EFI runtime services, but > this was not documented. To mitigate the impact, EFI runtime invocations > can be restricted to specific CPUs so that real‑time workloads on other > CPUs remain unaffected. This mechanism, however, is only described in > the commit that introduced it. > > This change adds a firmware section that documents these behaviours > explicitly. It highlights cases where firmware can delay the kernel, > information that may be unfamiliar to some users and surprising-or > concerning-to others. > > Assisted-by: Microsoft-Copilot > Signed-off-by: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de> > --- > > I would appreciate an ACK from the OP-TEE camp that I got my little > research right. > > Documentation/core-api/real-time/hardware.rst | 92 +++++++++++++++++++ > 1 file changed, 92 insertions(+) > > diff --git a/Documentation/core-api/real-time/hardware.rst b/Documentation/core-api/real-time/hardware.rst > index 19f9bb3786e03..fb113848c2f70 100644 > --- a/Documentation/core-api/real-time/hardware.rst > +++ b/Documentation/core-api/real-time/hardware.rst > @@ -130,3 +130,95 @@ https://github.com/Linutronix/RTC-Testbench. > The goal of this project is to validate real-time network communication. It can > be thought of as a "cyclictest" for networking and also serves as a starting > point for application development. > + > +Firmware > +-------- > + > +The firmware often plays a significant role in system operation because it can > +perform tasks that the kernel cannot directly access, and in some cases it can > +even preempt or intercept the kernel. > + > +A common example of firmware assisting the kernel is when it provides a generic > +interface to a resource. Instead of accessing an RTC chip through an I2C host > +controller, the kernel may query the firmware for the current time, and the > +firmware then accesses the RTC behind the scenes. > + > +Firmware can also intercept kernel execution by providing services that > +temporarily take control of the system. One example is memory scrubbing, where > +the firmware periodically pauses the kernel, reads back portions of system > +memory, and then returns control. During this time, the kernel is effectively > +interrupted. > +In contrast, some systems provide hardware‑based memory scrubbing, which > +operates independently of firmware or software. See > +Documentation/edac/scrub.rst for details. > + > +If the kernel is intercepted for longer periods then these periods can be made > +visible with the hardware latency detector. See > +Documentation/trace/hwlat_detector.rst. > + > +The kernel can also be intercepted in response to specific events, such as > +overheating. In this case, the firmware may throttle the CPU or shut it down > +immediately to prevent hardware damage. > + > +Unless the firmware is well documented, it should be thoroughly tested to > +uncover any unexpected behaviour. > + > +EFI > +~~~~ > + > +EFI provides runtime services that act as a communication interface between the > +firmware and the operating system. One such service is reading and writing EFI > +variables, which are used, for example, to determine the boot source. > + > +Invoking a runtime service may require the architecture to disable kernel > +preemption or interrupts during the call. This means the duration of a service > +invocation directly affects the system’s observable latency. There is also > +nothing that prevents a service call from disabling interrupts internally while > +it runs. > + > +For these reasons, EFI runtime services are disabled by default on a PREEMPT_RT > +kernel. They can still be enabled at boot time or via a Kconfig option if > +required. > +The native EFI runtime service implementation (where both the EFI service and > +the kernel are either 32‑bit or 64‑bit executables) uses a wrapper mechanism > +that invokes the service through a dedicated workqueue. This workqueue is named > +efi_runtime, and it can be restricted to a housekeeping CPU using the > +``/sys/devices/virtual/workqueue/efi_runtime/cpumask`` sysfs file. Assigning it > +to a housekeeping CPU ensures that potentially long service invocations do not > +impact the real‑time workload which is restricted to other CPUs. > + > +It must also be verified that the runtime services behave as expected. Some > +implementations on the x86 architecture pause all other CPUs while one CPU > +performs the service call. In such cases, the interruption affects all CPUs, > +and restricting the workqueue to a single CPU provides no benefit. > + > +OP-TEE (ARM) > +~~~~~~~~~~~~ > + > +OP‑TEE uses a global serialization mechanism (the "big lock"), ensuring that on > +each core only one OP‑TEE thread executes secure‑world code at a time. > + > +Execution flows from the normal world (Linux) into the secure world (OP‑TEE) > +through the secure monitor at EL3. Linux and OP‑TEE cannot disable or mask each > +other’s interrupts because both run at EL1 in different security states. > + > +Architecturally, the secure monitor can mask or reroute normal‑world interrupts > +before entering the secure world. In a correct OP‑TEE/ TF‑A implementation, it > +does not do this for the duration of secure calls. Normal‑world interrupts > +remain deliverable, and a normal‑world IRQ will preempt OP‑TEE via EL3 and > +return control to Linux. > + > +Secure‑world interrupts (FIQs) are possible if the SoC routes a device's > +interrupt as secure. Such a secure FIQ will preempt Linux immediately, trap > +into EL3, and transfer control to OP‑TEE's secure interrupt handler. Linux > +cannot mask or preempt this. Secure FIQ handlers must therefore be extremely > +short to avoid introducing noticeable latency. > + > +The transition from normal world -> secure monitor -> OP‑TEE and back introduces > +additional latency due to world switching and context save/ restore. This > +overhead is typically a few microseconds and usually remains in the noise > +floor. > + > +If the secure monitor masks normal‑world interrupts during OP‑TEE invocations, > +or if OP‑TEE uses long‑running secure FIQ handlers, then OP‑TEE can introduce > +measurable latency spikes. > -- > 2.53.0 >

1 week, 5 days

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

OP-TEE