pith. sign in

arxiv: 1906.09799 · v2 · pith:66LG4CIZnew · submitted 2019-06-24 · 💻 cs.OS · cs.PF

On The Performance of ARM TrustZone

Julien Amacher , Valerio Schiavoni This is my paper

Pith reviewed 2026-05-25 17:02 UTC · model grok-4.3

classification 💻 cs.OS cs.PF
keywords TrustZoneperformance evaluationOP-TEEtrusted execution environmentARM processorssecure storageenergy consumptionworld switch
0
0 comments X

The pith

TrustZone adds measurable time and energy costs for world switches and secure storage when used via OP-TEE.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper sets out to quantify the runtime and energy overheads introduced by ARM TrustZone on actual hardware and in emulation. It focuses on the cost of crossing between the normal and secure worlds and on the performance of secure storage operations inside the OP-TEE framework. A reader would care because these concrete numbers let developers judge whether the isolation TrustZone provides is worth the slowdown for a given workload.

Core claim

Using a combination of emulated and hardware measurements, the study shows that world switches and secure-storage accesses inside OP-TEE carry quantifiable performance and energy penalties that can be directly observed on contemporary ARM platforms.

What carries the argument

The OP-TEE framework's secure-world kernel and its world-switch mechanism, whose latency and energy cost are measured through targeted benchmarks.

If this is right

  • Application designers can use the reported switch costs to decide whether to place sensitive code inside the secure world.
  • Energy budgets for mobile or embedded devices can now include explicit TrustZone overhead terms.
  • Implementers of TEE frameworks can target the measured switch path for optimization.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Similar measurement campaigns on other TEEs could reveal whether the overhead profile is architecture-specific.
  • The numbers could serve as a baseline for future hardware changes that reduce world-switch latency.

Load-bearing premise

The chosen benchmarks and hardware platforms produce overhead numbers that generalize to other TrustZone deployments and real applications.

What would settle it

Repeating the same benchmarks on a different ARM platform or with production workloads yields overhead values that differ by more than a small constant factor.

Figures

Figures reproduced from arXiv: 1906.09799 by Julien Amacher, Valerio Schiavoni.

Figure 1
Figure 1. Figure 1: Sales and popularity of ARM processors in the last 20 years [5,4] security modules –HSM–), or regular chips to which security extensions were added. Examples of the latter include Intel’s Software Guard Extensions (i.e., SGX [21]) since the Skylake architecture (2015), or ARM’s TRUSTZONE [7] since ARMv6 (2008). ARM devices are often battery-powered and must therefore make optimal use of their limited energ… view at source ↗
Figure 2
Figure 2. Figure 2: TRUSTZONE components and interaction workflow. 2 Background This section provides some background on TRUSTZONE. First we define a few terms used throughout this paper. §2.1 describes TRUSTZONE’s main mechanisms and limi￾tations, while §2.2 introduces OP-TEE. Rich Execution Environment. The REE (or normal world) is the regular, non￾secure operating system of a device. The memory, registers, and caches are n… view at source ↗
Figure 3
Figure 3. Figure 3: Experimental setup and approach used to run our measurements to TEEC InitializeContext which returns a context object. The UUID is defined at compile-time and must be unique amongst all TAs. Next, this context is passed to TEEC OpenSession which returns a session. This session is then used to invoke ac￾tual services in the TA using the TEEC InvokeCommand, which takes as parameters the service identifier as… view at source ↗
Figure 4
Figure 4. Figure 4: Use of markers TEE kernel Syscall/RPC of interest Syscall t1: Start instrument. t2: Stop instrument. Store t=t2-t1 t: getDuration Execute Benchmark application Monitoring program KM001 Process CSV Start recording Stop recording Export CSV REE kernel opt [PITH_FULL_IMAGE:figures/full_fig_p007_4.png] view at source ↗
Figure 6
Figure 6. Figure 6: Idle (left) and burn (right) power consumption. Idle Burn Governor W BTU/h W BTU/h ondemand 0.78 2.66 3.08 10.51 performance 0.86 2.93 3.32 11.33 powersave 0.78 2.66 1.65 5.63 [PITH_FULL_IMAGE:figures/full_fig_p009_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: Basic TA operations: loading, unloading and suc￾cessive calls to load/unload the same TA. For each configuration, [PITH_FULL_IMAGE:figures/full_fig_p009_7.png] view at source ↗
Figure 8
Figure 8. Figure 8: World switching performance and energy requirements compared to the first loading, despite the tee-supplicant is sup￾posed to cache the TA code. We will investigate this aspect in fu￾ture work. Context (World) Switching. Switching between worlds is a key operation when deploying applications that execute inside and outside the TRUSTZONE. To measure the switching time, we implemented an ad-hoc benchmark mad… view at source ↗
Figure 10
Figure 10. Figure 10: Energy: memory accesses serve how the operations in the TEE↔TEE case are on average 2× faster on bare metal and 1.2× under emulation than in the other cases. Secure Storage: performance. We evaluate the performance of TRUSTZONE’s se￾cure storage via the corresponding GlobalPlatform’s API implemented by OP-TEE. Specifically, we benchmark the cost of creating, writing, reading and closing objects in￾side th… view at source ↗
Figure 11
Figure 11. Figure 11: Secure storage: basic operations (left) and iteration (right) Secure storage − energy used 0 100 200 300 400 500 Close&delete 1kB file Close&delete 10kB file Close 1kB file Close 10kB file Create file Open 1kB file Open 10kB file Write 1kB file Write 10kB file Energy [µWh] rpi3b ondemand rpi3b performance rpi3b powersave [PITH_FULL_IMAGE:figures/full_fig_p012_11.png] view at source ↗
Figure 12
Figure 12. Figure 12: Secure storage: energy measurements for basic operations Secure Storage: energy. Being a feature often used by nomad devices with low energy autonomy, we deeply investigate its energy impacts [PITH_FULL_IMAGE:figures/full_fig_p012_12.png] view at source ↗
Figure 13
Figure 13. Figure 13: Secure storage, energy to iterate (top) and rename (bottom) Secure storage breakdown Create file Write file Execution time [%]100 0 100 0 1kB 1. open dir 2. get temp file handle 3. open 4. write 5. sync htree 6. set name Create file Write file Execution time [%]100 0 100 0 10kB Create file Write file Execution time [%]100 0 100 0 100kB Create file Write file Execution time [%]100 0 100 0 1MB ondemand perf… view at source ↗
Figure 14
Figure 14. Figure 14: Secure storage breakdown for two operations: create and write cores, we observe an increase of energy consumption. Overall, in this benchmark the ondemand governor is the most energy eager. This can be explained by the fact that ad￾justing the core frequencies (from 600MHz and 1.2GHz) seems to be a relatively costly operation [41]. Thermal benchmarks. We conclude our evaluation by looking at the thermal e… view at source ↗
Figure 15
Figure 15. Figure 15: CPU benchmark: processing delay and energy requirements. CPU temperature during prime benchmark 20 30 40 50 60 70 80 90 0 4 8 12 16 Temperature [°C] ondemand External sensor Thermals API External sensor (w/ fan) Thermals API (w/ fan) #1 #2 Time [min] 0 4 8 12 16 powersave #3 #4 0 4 8 12 16 Max Ambient performance #5 #6 [PITH_FULL_IMAGE:figures/full_fig_p014_15.png] view at source ↗
Figure 16
Figure 16. Figure 16: Evolution of CPU temperature with different cooling modes and governors. temperature exceeds the rated continuous temperature of 85°C specified by the chip’s manufacturer. In this situation, the thermals API returns an incorrect temperature that is well below the acceptable temperature. As a consequence measures which should be taken to reduce the temperature, such as software thermal throttling, are not … view at source ↗
Figure 17
Figure 17. Figure 17: Raspberry Pi thermal behaviour during processor stress benchmarks. 5 Lessons Learned This section reports on a few lessons learned during this experimental work. Memory limitations. By default, 32MB are dedicated to OP-TEE, of which: 1MB for TEE memory, 1MB for PUB (non-secure RAM) memory, and the remaining 30MB for TAs. Each TA has two compile-time options, TA STACK SIZE and TA DATA SIZE (in user ta head… view at source ↗
read the original abstract

The TrustZone technology, available in the vast majority of recent ARM processors, allows the execution of code inside a so-called secure world. It effectively provides hardware-isolated areas of the processor for sensitive data and code, i.e., a trusted execution environment (TEE). The OP-TEE framework provides a collection of toolchain, open-source libraries and secure kernel specifically geared to develop applications for TrustZone. This paper presents an in-depth performance- and energy-wise study of TrustZone using the OP-TEE framework, including secure storage and the cost of switching between secure and unsecure worlds, using emulated and hardware measurements.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

1 major / 0 minor

Summary. The paper presents an empirical performance and energy study of ARM TrustZone using the OP-TEE framework. It reports measurements of secure storage operations and the overhead of switching between secure and non-secure worlds, performed on both emulated and physical hardware platforms.

Significance. If the reported measurements are reproducible and include appropriate controls, the work supplies concrete overhead numbers for a widely deployed TEE technology. Such data can guide developers in assessing when TrustZone is suitable for sensitive workloads.

major comments (1)
  1. [Abstract and §3] Abstract and §3 (Methodology): the description of the measurement campaign provides no information on the specific workloads or benchmarks executed, the number of repetitions, statistical methods for aggregating results, error bars, or baseline comparisons against non-TrustZone execution. Without these details the reliability of the reported performance and energy numbers cannot be assessed.

Simulated Author's Rebuttal

1 responses · 0 unresolved

We thank the referee for the constructive review and positive recommendation. We address the single major comment below.

read point-by-point responses

  1. Referee: [Abstract and §3] Abstract and §3 (Methodology): the description of the measurement campaign provides no information on the specific workloads or benchmarks executed, the number of repetitions, statistical methods for aggregating results, error bars, or baseline comparisons against non-TrustZone execution. Without these details the reliability of the reported performance and energy numbers cannot be assessed.

    Authors: We agree that the abstract and §3 do not supply these details. The experimental campaign did execute concrete workloads (secure storage operations and world-switch micro-benchmarks) on both QEMU and hardware, with multiple repetitions, but the presentation omitted the required methodological information. In the revised manuscript we will expand the abstract and §3 to describe the exact workloads and benchmarks, the number of repetitions performed, the statistical methods used to aggregate results, the inclusion of error bars, and direct baseline comparisons against equivalent non-TrustZone execution paths. revision: yes

Circularity Check

0 steps flagged

No significant circularity identified

full rationale

The paper is a purely empirical measurement study of TrustZone/OP-TEE performance and energy costs on emulated and real hardware. It reports benchmark results for secure storage and world-switch overheads without any derivations, first-principles predictions, fitted parameters presented as predictions, or load-bearing self-citations. The central claim is simply that the authors performed and documented these measurements; no quantitative generalization or model is asserted that would require the results to reduce to their own inputs.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

Empirical benchmarking paper; no free parameters, axioms, or invented entities are introduced or required.

pith-pipeline@v0.9.0 · 5619 in / 1003 out tokens · 21293 ms · 2026-05-25T17:02:55.208561+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

57 extracted references · 57 canonical work pages · 1 internal anchor

  1. [1]

    http://infocenter.arm.com/ help/index.jsp?topic=/com.arm.doc.den0024a/ch10s02s04.html

    AArch64 Exception Handling - System calls to EL2/EL3. http://infocenter.arm.com/ help/index.jsp?topic=/com.arm.doc.den0024a/ch10s02s04.html

    work page

  2. [2]

    https://source.android.com/security/trusty

    Android Trusty TEE. https://source.android.com/security/trusty

    work page

  3. [3]

    https://www.arctic.ac/ch_en/mx-4.html

    Arctic MX-4. https://www.arctic.ac/ch_en/mx-4.html

    work page

  4. [4]

    https://hexus.net/static/arm-everywhere/

    ARM Everywhere. https://hexus.net/static/arm-everywhere/

    work page

  5. [5]

    https://www.arm.com/company/investors/ financial-results

    ARM Financial Results. https://www.arm.com/company/investors/ financial-results

    work page

  6. [6]

    https://community.arm.com/processors/b/blog/ posts/inside-the-numbers-100-billion-arm-based-chips-1345571105

    ARM Inside The Numbers - 100bn. https://community.arm.com/processors/b/blog/ posts/inside-the-numbers-100-billion-arm-based-chips-1345571105

    work page

  7. [7]

    https://developer.arm.com/technologies/trustzone

    ARM TrustZone Developer. https://developer.arm.com/technologies/trustzone

    work page

  8. [8]

    Secure Monitor Call (SMC)

    ARM1176JZF-S Technical Reference Manual - 2.12.13. Secure Monitor Call (SMC). http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0301h/ ch02s12s13.html

    work page

  9. [9]

    https://github.com/OP-TEE/optee_os/blob/master/ documentation/benchmark.md

    Benchmark framework. https://github.com/OP-TEE/optee_os/blob/master/ documentation/benchmark.md

    work page

  10. [10]

    https://linux.die.net/man/3/clock_gettime

    clock gettime(3) - Linux man page. https://linux.die.net/man/3/clock_gettime

    work page

  11. [11]

    https://docs.microsoft.com/en-us/ dotnet/framework/interop/consuming-unmanaged-dll-functions

    Consuming Unmanaged DLL Functions. https://docs.microsoft.com/en-us/ dotnet/framework/interop/consuming-unmanaged-dll-functions

    work page

  12. [12]

    Memory Access Sequence

    Cortex-A9 Technical Reference Manual - 6.3. Memory Access Sequence. http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0388f/ Ciheiecd.html. Accessed: 2018-12-09

    work page 2018

  13. [13]

    https://nvd.nist.gov/vuln/detail/CVE-2017-5715

    CVE-2017-5715. https://nvd.nist.gov/vuln/detail/CVE-2017-5715

    work page 2017

  14. [14]

    https://nvd.nist.gov/vuln/detail/CVE-2017-5753

    CVE-2017-5753. https://nvd.nist.gov/vuln/detail/CVE-2017-5753

    work page 2017

  15. [15]

    https://nvd.nist.gov/vuln/detail/CVE-2017-5754

    CVE-2017-5754. https://nvd.nist.gov/vuln/detail/CVE-2017-5754

    work page 2017

  16. [16]

    https://nvd.nist.gov/vuln/detail/CVE-2018-3639

    CVE-2018-3639. https://nvd.nist.gov/vuln/detail/CVE-2018-3639

    work page 2018

  17. [17]

    https://www.flir.com/products/e4/

    Flir E4. https://www.flir.com/products/e4/

    work page

  18. [18]

    https://linux.die.net/man/2/gettimeofday

    gettimeofday(2) - Linux man page. https://linux.die.net/man/2/gettimeofday

    work page

  19. [19]

    https://github.com/ OP-TEE/optee_os/issues/1396

    Hikey: trying to allocate more physical memory to secure world. https://github.com/ OP-TEE/optee_os/issues/1396

    work page

  20. [20]

    https://github.com/OP-TEE/optee_os/ issues/2090

    How to alloc 10M memory by TEE Malloc(). https://github.com/OP-TEE/optee_os/ issues/2090

    work page 2090

  21. [21]

    https://software.intel.com/en-us/sgx

    Intel SGX. https://software.intel.com/en-us/sgx

    work page

  22. [22]

    https://www.kingston.com/en/embedded/emmc

    Kingston Embedded Solutions. https://www.kingston.com/en/embedded/emmc

    work page

  23. [23]

    https://github.com/Microsoft/openenclave

    Microsoft OpenEnclave Framework. https://github.com/Microsoft/openenclave

    work page

  24. [24]

    https://github.com/OP-TEE/build

    OP-TEE Build on Github. https://github.com/OP-TEE/build. Accessed: 2018-12-04

    work page 2018

  25. [25]

    https://github.com/OP-TEE/OP-TEE_website/tree/ master/faq

    OP-TEE FAQ on Github. https://github.com/OP-TEE/OP-TEE_website/tree/ master/faq. Accessed: 2018-12-04

    work page 2018

  26. [26]

    https://github.com/OP-TEE/optee_os

    OP-TEE OS on Github. https://github.com/OP-TEE/optee_os. Accessed: 2018-12-04

    work page 2018

  27. [27]

    https://www.op-tee.org/ docs/rpi3/

    OP-TEE Raspberry 3B platform specific documentation. https://www.op-tee.org/ docs/rpi3/

    work page

  28. [28]

    https://github.com/OP-TEE/optee_test

    OP-TEE sanity testsuite on Github. https://github.com/OP-TEE/optee_test. Ac- cessed: 2018-12-04

    work page 2018

  29. [29]

    https://github.com/OP-TEE/optee_os/blob/master/core/arch/ arm/kernel/generic_entry_a64.S

    OP-TEE source. https://github.com/OP-TEE/optee_os/blob/master/core/arch/ arm/kernel/generic_entry_a64.S. Accessed: 2018-12-09

    work page 2018

  30. [30]

    https://github.com/OP-TEE/optee_client/tree/ master/tee-supplicant

    OP-TEE Supplicant on Github. https://github.com/OP-TEE/optee_client/tree/ master/tee-supplicant. Accessed: 2018-12-04

    work page 2018

  31. [31]

    https://github.com/OP-TEE/optee_os/ blob/master/core/arch/arm/kernel/thread.c#L150

    OPTEE-OS kernel thread.c init canaries. https://github.com/OP-TEE/optee_os/ blob/master/core/arch/arm/kernel/thread.c#L150. 18 Julien Amacher and Valerio Schiavoni

    work page

  32. [32]

    http://www.chargerlab.com/archives/536.html

    POWER-Z KM001C. http://www.chargerlab.com/archives/536.html

    work page

  33. [33]

    https://www.qemu.org

    Qemu. https://www.qemu.org. Accessed: 2018-12-04

    work page 2018

  34. [34]

    https://git.linaro.org/virtualization/ qemu-tz.git

    QEMU with WIP TrustZone Support. https://git.linaro.org/virtualization/ qemu-tz.git

    work page

  35. [35]

    https://github.com/OP-TEE/optee_os/ issues/1523

    Shared memory size bigger than 1MB. https://github.com/OP-TEE/optee_os/ issues/1523

    work page

  36. [36]

    https://kernel.ubuntu.com/˜cking/stress-ng/

    Stress-NG. https://kernel.ubuntu.com/˜cking/stress-ng/. Accessed: 2019-20-01

    work page 2019

  37. [37]

    https://github.com/ OP-TEE/optee_os/issues/2577

    TEE BigIntAdd fails when dest=op OP-TEE OS Issue #2577. https://github.com/ OP-TEE/optee_os/issues/2577

    work page

  38. [38]

    https://www.trustonic.com/solutions/ trustonic-solutions-iot

    TRUSTSONIC. https://www.trustonic.com/solutions/ trustonic-solutions-iot

    work page

  39. [39]

    https://github.com/OP-TEE/optee_os/ issues/2178

    Using more than 1Mb with TEE Malloc. https://github.com/OP-TEE/optee_os/ issues/2178

    work page

  40. [40]

    https://www.vmware.com/products/esxi-and-esx.html

    VMware ESXi. https://www.vmware.com/products/esxi-and-esx.html

    work page

  41. [41]

    https://www.ibm.com/developerworks/library/ l-cpufreq-3/

    Workloads and governor effects. https://www.ibm.com/developerworks/library/ l-cpufreq-3/

    work page

  42. [42]

    ARM® CoreLink™ TZC-400 TrustZone®Address Space Controller

    ARM. ARM® CoreLink™ TZC-400 TrustZone®Address Space Controller. 2014

    work page 2014

  43. [43]

    SMC CALLING CONVENTION System Software on ARM® Platforms

    ARM Limited. SMC CALLING CONVENTION System Software on ARM® Platforms. 2016

    work page 2016

  44. [44]

    Barbosa, S

    M. Barbosa, S. B. Mokhtar, P. Felber, F. Maia, M. Matos, R. Oliveira, E. Riviere, V . Schi- avoni, and S. V oulgaris. SAFETHINGS: Data Security by Design in the IoT. InDependable Computing Conference (EDCC), 2017 13th European, pages 117–120. IEEE, 2017

    work page 2017

  45. [45]

    H. Cho, P. Zhang, D. Kim, J. Park, C.-H. Lee, Z. Zhao, A. Doup ´e, and G.-J. Ahn. Prime+Count: Novel Cross-world Covert Channels on ARM TrustZone. In Proceedings of the 34th Annual Computer Security Applications Conference , ACSAC ’18, pages 441–452, New York, NY , USA, 2018. ACM

    work page 2018

  46. [46]

    CPU frequency and voltage scaling code in the Linux(tm) kernel

    Dominik Brodowski. CPU frequency and voltage scaling code in the Linux(tm) kernel

    work page

  47. [47]

    Leading the IoT Gartner Insights on How to Lead in a Connected World

    Gartner. Leading the IoT Gartner Insights on How to Lead in a Connected World. 2017

    work page 2017

  48. [48]

    Greenhalgh

    P. Greenhalgh. big.LITTLE processing with arm cortex-a15 & cortex-a7. ARM White paper, 17, 2011

    work page 2011

  49. [49]

    Z. Hua, J. Gu, Y . Xia, H. Chen, B. Zang, and H. Guan. vTZ: Virtualizing ARM trustzone. In In Proc. of the 26th USENIX Security Symposium, 2017

    work page 2017

  50. [50]

    Lentz, R

    M. Lentz, R. Sen, P. Druschel, and B. Bhattacharjee. SeCloak: ARM Trustzone-based Mobile Peripheral Control. pages 1–13, 06 2018

    work page 2018

  51. [51]

    M. Lipp, M. T. Aga, M. Schwarz, D. Gruss, C. Maurice, L. Raab, and L. Lamster. Nethammer: Inducing Rowhammer Faults through Network Requests. arXiv preprint arXiv:1805.04956, 2018

    work page internal anchor Pith review Pith/arXiv arXiv 2018

  52. [52]

    McGillion, T

    B. McGillion, T. Dettenborn, T. Nyman, and N. Asokan. Open-TEE–An Open Virtual Trusted Execution Environment. In Proceedings of the 2015 IEEE Trustcom/BigDataSE/ISPA-Volume 01, pages 400–407. IEEE Computer Society, 2015

    work page 2015

  53. [53]

    Implementing practical electrical glitching attacks, 2015

    ncc group. Implementing practical electrical glitching attacks, 2015

    work page 2015

  54. [54]

    TRUSTED LITTLE KERNEL (TLK) FOR TEGRA: FOSS EDITION

    nVidia. TRUSTED LITTLE KERNEL (TLK) FOR TEGRA: FOSS EDITION. 2015

    work page 2015

  55. [55]

    A. K. Reddy, P. Paramasivam, and P. B. Vemula. Mobile secure data protection using eMMC RPMB partition. In Computing and Network Communications (CoCoNet), 2015 Interna- tional Conference on, pages 946–950. IEEE, 2015

    work page 2015

  56. [56]

    Technology

    G. Technology. GlobalPlatform TEE Client API Specification v1.0

    work page

  57. [57]

    bcm2835_thermal

    G. Technology. TEE Internal Core API Specification Version 1.1.2.50. 2018. On The Performance of ARM TrustZone 19 A Appendix: Extending the Kernel First, a new file containing the syscall used to retrieve the processor temperaturegetc- putemp is created. 1 // populates temp with the CPU temperature in [m degC] 2 SYSCALL_DEFINE1(getcputemp, unsigned long *, ...

    work page 2018