PaperlayerView exact revision on arXiv

Source-linked AI summary

TrustShadow: Secure Execution of Unmodified Applications with ARM TrustZone

Le Guan, Peng Liu, Xinyu Xing, Xinyang Ge, Shengzhi Zhang, Meng Yu, Trent Jaeger

arXiv:1704.05600v2cs.CRcs.OS

TL;DR

Commodity operating systems on ARM-based IoT devices can be compromised, exposing sensitive application data, while existing protections may require unsuitable hardware, resources, or application changes. TrustShadow uses ARM TrustZone and a lightweight runtime to protect unmodified applications by forwarding and verifying OS service requests, and the paper reports comprehensive protection with negligible or occasionally moderate overhead. Its scope excludes availability and side-channel attacks and assumes the secure-world runtime is trusted.

  • Problem

    Compromised commodity OSes can expose sensitive data on ARM-based IoT devices, while existing protections may require unavailable hardware, substantial resources, or application and OS re-engineering.

  • Method

    TrustShadow uses ARM TrustZone to isolate security-critical applications and a lightweight runtime that forwards OS service requests and verifies their responses without modifying applications.

  • Results

    TrustShadow comprehensively protects security-critical applications against total OS compromise without application modification and imposes only negligible, occasionally moderate, overhead on IoT devices.

  • Takeaways & Limitations

    TrustShadow provides lightweight protection for legacy applications on ARM-based multi-programming IoT devices without requiring application re-engineering.

  • Takeaways & Limitations

    The threat model excludes availability and timing or power side-channel attacks and assumes the TrustZone runtime system is trusted.

Abstract

from arXiv · show

The rapid evolution of Internet-of-Things (IoT) technologies has led to an emerging need to make it smarter. A variety of applications now run simultaneously on an ARM-based processor. For example, devices on the edge of the Internet are provided with higher horsepower to be entrusted with storing, processing and analyzing data collected from IoT devices. This significantly improves efficiency and reduces the amount of data that needs to be transported to the cloud for data processing, analysis and storage. However, commodity OSes are prone to compromise. Once they are exploited, attackers can access the data on these devices. Since the data stored and processed on the devices can be sensitive, left untackled, this is particularly disconcerting. In this paper, we propose a new system, TrustShadow that shields legacy applications from untrusted OSes. TrustShadow takes advantage of ARM TrustZone technology and partitions resources into the secure and normal worlds. In the secure world, TrustShadow constructs a trusted execution environment for security-critical applications. This trusted environment is maintained by a lightweight runtime system that coordinates the communication between applications and the ordinary OS running in the normal world. The runtime system does not provide system services itself. Rather, it forwards requests for system services to the ordinary OS, and verifies the correctness of the responses. To demonstrate the efficiency of this design, we prototyped TrustShadow on a real chip board with ARM TrustZone support, and evaluated its performance using both microbenchmarks and real-world applications. We showed TrustShadow introduces only negligible overhead to real-world applications.

1. INTRODUCTION

IoT edge devices run legacy applications on ARM-based commodity operating systems, but compromised OSes can expose sensitive data. TrustShadow uses ARM TrustZone and a lightweight forwarding-and-verifying runtime to protect unmodified applications with negligible reported overhead.

  • Commodity OS compromise can give attackers complete access to sensitive data processed on ARM-based IoT devices.
  • Existing protections are difficult to apply because IoT devices lack some PC hardware, have limited resources, and often require application or OS changes.
  • TrustShadow uses ARM TrustZone to construct a trusted execution environment that shields legacy applications from compromised OSes without changing applications or radically changing existing OSes.
  • Its lightweight runtime manages application page tables locally, forwards system-service requests to the untrusted OS, and verifies returned data.
  • TrustShadow reduces trusted-computing-base complexity by relying on the OS for system services while protecting legacy applications from untrusted OSes.
  • A prototype used about 5.3K secure-world lines of code and 300 normal-world lines, with negligible performance overhead in microbenchmarks and real-world software.

2. RELATED WORK

Prior work protects applications using hypervisors, hardware features, or code instrumentation, but these approaches can conflict with IoT resource, hardware, and compatibility constraints. TrustShadow instead targets ARM TrustZone and avoids complex hypervisor resource allocation.

  • Hypervisors and Virtual Machines: Hypervisor-based systems encrypt application address spaces and verify memory integrity, but their overhead and hardware requirements limit adoption on resource-constrained IoT devices.
  • Hypervisors and Virtual Machines: Virtualization extensions are absent from many existing ARM devices, while newer IoT-oriented Cortex-M processors incorporate TrustZone instead.
  • Hypervisors and Virtual Machines: TrustShadow uses TrustZone to mediate OS-application communication and eliminate complex, error-prone hypervisor resource allocation.
  • Hardware Features: Hardware-feature approaches such as Intel SGX and TPM protect applications through platform-specific trusted regions or hardware roots of trust.
  • Hardware Features: TrustZone-based systems such as TLR, VeriUI, and TrustOTP protect specialized application components or interactions rather than unmodified general-purpose applications.
  • Code Instrumentation: Virtual Ghost uses compiler instrumentation and runtime checking, increasing kernel privileged code, trusted-computing-base size, and performance overhead.

3. TRUSTZONE

ARM TrustZone partitions SoC resources between secure and normal worlds while allowing one processor core to execute both safely. Its controllers and separate virtual MMUs enforce or manage access across those worlds.

  • TrustZone partitions SoC hardware and software resources into a secure world and a normal world executed by one processor core in time-sliced fashion.
  • The NS-bit on the AMBA AXI bus lets processors check whether accesses target secure or non-secure resources.
  • Monitor-mode software saves and restores world state during switches, with secure-world entry performed through an smc instruction.
  • Address Space Controller: TZASC configures access permissions for address regions and blocks non-secure reads and writes to secure-only memory.
  • Memory Management Unit: TrustZone-enabled processors provide separate virtual MMUs, allowing secure and normal worlds to map virtual addresses independently.
  • Memory Management Unit: The secure world can tune the NS field to access either secure or non-secure physical memory, enabling controlled memory sharing.

4. THREAT MODEL

TrustShadow assumes a completely compromised OS that can manipulate process memory, registers, services, and observable behavior. The threat model excludes availability and side-channel attacks while trusting the secure-world runtime.

  • The threat model grants a compromised OS system privilege to read or write victim memory and registers, enabling disclosure and code-injection attacks.
  • The OS may forge system-call responses or infer data from page-fault patterns, covering Iago and controlled-channel attacks.
  • Availability is out of scope because a compromised OS can refuse to boot or deny HAP time slices to cause denial of service.
  • Timing and power side channels are also out of scope, and the TrustZone runtime system is assumed trusted.
  • TrustShadow keeps runtime functionality and code minimal to facilitate correctness assurance through formal verification or manual review.

5. OVERVIEW

TrustShadow protects a shadow copy of each high-assurance application in the secure world while Linux remains in the normal world. A lightweight runtime coordinates execution, forwards most exceptions and system services, and locally handles security-sensitive operations.

  • Architecture: TrustShadow runs a shadow HAP in the secure world while its zombie counterpart in the normal world is never scheduled.The secure-world runtime supports execution of the protected application.
  • Runtime coordination: The runtime forwards exceptions and system-service requests to Linux instead of implementing those services itself.This design keeps the secure-world codebase small while coordinating communication across worlds.
  • Runtime coordination: The context switch module preserves HAP CPU state and clears general-purpose registers to avoid leaking sensitive data to Linux.It serves as the gateway for exceptions and their returns.
  • Internal exception handling: TrustShadow handles floating-point exceptions and random-number requests inside the secure world.The internal handlers avoid exposing floating-point registers and provide trustworthy randomness for cryptographic operations.
  • Runtime coordination: A marshaling buffer shares system-call parameters and returns, with copied results accepted only after verifier validation.The normal OS cannot directly access a shadow HAP.

6. RUNTIME SYSTEM

The runtime system isolates application memory and page tables in TrustZone while using Linux handlers through validated forwarding. It protects loaded code and protected files with integrity checks, encryption, and trusted randomness.

  • Memory management: TrustShadow partitions memory into normal and secure regions and mirrors Linux’s 2G/2G virtual-address split for legacy code.Secure regions hold the runtime and shadow HAPs, while the normal region holds Linux and ordinary processes.
  • Exception forwarding: The runtime intercepts exceptions and redirects most of them to Linux, preserving the processor state needed for transparent handling.Floating-point computation and random-number generation are handled internally.
  • Page-table protection: Secure page tables prevent a hostile OS from tampering with mappings, while Linux’s page-fault handler supplies updates that the runtime validates.The runtime checks returned information before installing page-table entries.
  • Page-table updates: For anonymous memory, TrustShadow duplicates Linux’s page-table entry only after confirming the mapped page lies in ZONE_TZ_APP.The Linux and runtime entries point to the same secure page S.
  • Integrity checking: For executable pages, the runtime allocates a secure page, copies the OS-loaded page into it, and verifies integrity there.Verification on the secure page makes the mechanism resilient to TOCTTOU attacks and applies to PT_LOAD segments.
  • Manifest design: The manifest contains an application key, integrity metadata, and protected filenames, while encryption and digital signatures protect its confidentiality and integrity.The manifest’s per-application secret key is encrypted with a per-device public key, and its content is digitally signed.

7. IMPLEMENTATION

TrustShadow was implemented on an ARM development board across secure- and normal-world components, including a secure boot sequence and Linux modifications. Its evaluation uses LMbench microbenchmarks to measure system-operation overhead.

  • Platform: TrustShadow was implemented on a Freescale i.MX6q board with an ARM Cortex-A9, 1GB DDR3 DRAM, and 256KB iRAM.The prototype spans operations in both the normal and secure worlds.
  • Normal world: The normal-world Linux distribution was modified to reserve HAP memory, allocate pages from it, identify HAPs, and add supporting functionality.The changes targeted Linux kernel version 3.18.24.
  • Secure world: The secure-world runtime used about 4.5K lines of ANSI C and 0.8K lines of assembly, alongside a secure boot mechanism.The boot mechanism verifies the runtime image before execution.
  • Secure boot: Secure boot configures and locks TrustZone access policies for ZONE_TZ_RT, ZONE_NORMAL, and ZONE_TZ_APP.Changing the locked policy requires a system reboot.
  • Secure boot: Linux retrieves the manifest and encrypted key pair, passes them to the runtime for decryption and installation, and then resumes execution.The board’s 256-bit ZMK protects the stored key pair from Linux.

8. EVALUATION

TrustShadow was evaluated on an i.MX6q board using microbenchmarks, I/O tests, and real-world applications. It adds substantial overhead to some individual system operations and protected file writes, but application-level overhead is generally small.

  • Evaluation setup: TrustShadow was evaluated on a Freescale i.MX6q board against native Linux using microbenchmarks, I/O tests, and real-world applications.The evaluation covered primitive OS operations, file I/O, an embedded web server, and machine-learning applications.
  • Microbenchmarks: TrustShadow's fork+exit, fork+exec, and signal-handler-install operations each incur about 2.36x overhead.The first two costs arise from populating marshaling buffers, while signal-handler installation copies a signal stack between worlds.
  • Microbenchmarks: Across most Table 1 test cases, TrustShadow's overhead is lower than InkTag and VirtualGhost because it avoids virtual machines and extensive kernel instrumentation.The comparison values for InkTag and VirtualGhost were taken from their published articles rather than reproduced experimentally.
  • File Operations: File protection increases write slowdown from about 1.09x without protection to about 2.71x with protection for sequential and random writes.The added cost comes from encryption and hashing when pages are synchronized to persistent storage; caching was disabled for the experiment.
  • Embedded Web Server: For Nginx over HTTP, throughput drops 6%–10% for small files but only 2% above 256 KB, with nearly no measured 95th-percentile latency overhead.TrustShadow introduced nearly no throughput overhead for HTTPS traffic across requested file sizes.
  • Data Analytics: TrustShadow classifies 60,000 images in 998 seconds, only 4 seconds slower than native Linux, and recognizes faces in 163.271 versus 162.591 seconds.These experiments used image classification and face-recognition applications to assess data-analysis workloads.

9. DISCUSSION AND FUTURE WORK

TrustShadow’s discussion examines its security guarantees, trusted-computing-base size, remaining attack surfaces, and future defenses against physical attacks. The system protects applications while relying on a compact runtime and leaving some threats for future work.

  • HAP Security: TrustShadow protects applications through load-time integrity verification, runtime resource isolation, and cryptographic protection of files and metadata.The OS can access only the marshaling buffer during execution, while protected files cannot be read or modified.
  • Runtime System Security: The runtime system’s security depends on verified loading, isolation from the ordinary OS, a narrow interface, application review, and user-level execution of HAPs.The runtime image is verified using a public key whose hash is burned into chip fuses.
  • TCB Size: The runtime system has about 5.3K LOC, compared with hundreds of thousands of lines for several hypervisors and millions of lines for Haven’s LibOS.VirtualGhost is identified as the only compared solution with a comparable TCB size.
  • Remaining Attack Surface: Because TrustShadow relies on the OS for system services, a compromised OS can launch denial-of-service attacks or invoke normal execution, though normal-world processes cannot access protected files.This reliance reduces the TCB but leaves scheduling and invocation under OS control.
  • Remaining Attack Surface: Manifest forgery is mitigated with per-device signatures, but rollback attacks remain a future-work target requiring manifest version numbers and remote updates.The proposed defense periodically communicates updated trusted-program versions between the runtime and a remote server.
  • Remaining Attack Surface: TrustShadow’s current design may remain subject to side-channel attacks that extract information across processes or virtual machines.The paper identifies existing mitigation techniques, including side-channel-resistant cryptographic libraries, as a possible response.
  • Future Work: Physical attacks on DRAM remain a future-work concern, while placing the protected region in iRAM can improve resistance for low-footprint programs.A 256KB iRAM board successfully ran a program generating a 2048-bit RSA key-pair, but limited capacity restricts this feature.

10. CONCLUSION

TrustShadow shields applications on multi-programming IoT devices with a carefully designed runtime system. It avoids application modification and imposes only negligible, occasionally moderate, overhead.

  • 10. CONCLUSION: TrustShadow shields applications on multi-programming IoT devices without requiring application modification or re-engineering.The conclusion frames this protection as applying even under total OS compromise.
  • 10. CONCLUSION: TrustShadow provides lightweight protection because its overhead is negligible and occasionally moderate on IoT devices.The conclusion presents the system as a basis for further research in IoT computing.

A. CODE SNIPPET OF EXCEPTION FORWARDING

The snippet forwards an SVC exception from the secure runtime to the normal OS by restoring the OS context, switching to non-secure state, and branching to the SVC handler.

  • Exception preparation: The code starts in monitor mode and prepares SVC as the target mode before forwarding control.It sets the saved program status register to SVC with interrupts masked, then switches to SVC mode.
  • Context restoration: The routine loads the user-space CPU context and restores critical registers required by the normal OS.It retrieves the context pointer, loads the context, reads CPSR, and restores stack pointers for SVC, abort, and IRQ modes.
  • System-call state: The routine restores syscall arguments in r0-r6 and the syscall number in r7 before transferring execution.These registers are prepared for the normal OS's system-call handler.
  • Security-state transition: The code changes the security state to non-secure by toggling the NS bit in the control register.It XORs the NS bit and writes the result through the coprocessor control-register instruction.
  • Exception forwarding: The routine branches to 0xFFFF0008, the normal OS's SVC exception-handler offset, completing exception forwarding.The target address is constructed in r8 before moving the program counter to it.
Loading 1704.05600v2…