Abstract

While trusted execution environments (TEEs) provide industry standard security and isolation, TEE requests through secure monitor calls (SMCs) attribute to large time overhead and weakened temporal predictability. Moreover, as current available TEE solutions are designed for Linux and/or Android initially, it will encounter many constraints (e.g., driver libraries incompatible, large memory footprint, etc.) when integrating with low-end Real-Time Operating Systems, RTOSs. In this paper, we present MiniTEE to understand, evaluate and discuss the benefits and limitations when integrating TrustZone-assisted TEEs with RTOSs. We demonstrate how MiniTEE can be adequately exploited for meeting the real-time needs, while presenting a low performance overhead to the rich OSs (i.e., low-end RTOSs).

Highlights

  • As real-time embedded systems become more complex and interconnected, certain sections or parts of the systems may need to be protected to prevent unauthorized access, or isolated to ensure functional/non-functional correctness

  • We comprehensively discussed the obstacle of combing RTOS with current trusted execution environments (TEEs) solutions and propose a RTOS-friendly TEE solution with predictable and bounded overhead; We present a case study on a 3-Degree of Freedom (3DOF) control system to demonstrate the use case of M INI TEE; We conduct comprehensive evaluation on a realistic hardware platform, focusing on the overhead incurred by M INI TEE on the real-time properties to a legacy RTOS

  • Demo system booting time: As discussed in Section 4, M INI TEE creates all the TEE tasks after each platform reboot. This design may potentially harm system booting up time. In this particular demo system, we measured the overhead by comparing following two cases: (i) Native, which denotes the case that only initiates the TEE OS kernel during each reboot; and (ii) M INI TEE, which denotes the that all Trusted Applications (TAs) threads are initiated during each reboot

Read more

Summary

Introduction

As real-time embedded systems become more complex and interconnected, certain sections or parts of the systems may need to be protected to prevent unauthorized access, or isolated to ensure functional/non-functional correctness. The drone may communicate with the base station via real-time communication protocols to update mission-related information (e.g., new customer location). If those information are tampered with an ill-intentioned entity, the entire drone can be mis-routed, leading failed delivery [1]. Complex authentication mechanisms can improve system security, but at the price of introducing large overhead and degrading the real-time performance of the system [2]. ARM TrustZone technology [4] refers to a hardware security mechanism introduced since ARMv6 architecture, which includes security extensions to ARM System-On-Chip (SoC) covering the processor, memory and peripherals. ARM extends TrustZone to ARMv8-M architecture for the Cortex-M processor family [8]. The distinctive aspects of TrustZone for ARMv8-M are out of the scope of this paper

Methods
Results
Conclusion
Full Text
Published version (Free)

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call