From HAL to SMC : a normal-world view of ARM TrustZone on Android
TL;DR
The findings show that kernel-level data-transport and synchronization choices directly influence the classes of concurrency and memory-sharing defects exposed by each TEE architecture.
Abstract
ARM TrustZone provides hardware-enforced isolation for security-critical operations on Android devices. It separates execution into two worlds: the Normal World and the Secure World. Although security-sensitive operations execute in the Secure World, each operation must first be initiated, marshaled, and dispatched by software running in the Normal World. Despite the security relevance of this interface, there is limited systematic cross-platform documentation of the Normal-World software stacks that support it. This work reconstructs the end-to-end Normal-World data path, from the Hardware Abstraction Layer (HAL) interface to the Secure Monitor Call (SMC) boundary, for three commercially deployed Trusted Execution Environment (TEE) implementations: Qualcomm QSEE, Samsung TEEGris, and Google Trusty. Gatekeeper credential verification serves as a common case study across the three platforms. This analysis shows that the three stacks rely on fundamentally different data-transport mechanisms. QSEE passes physical addresses of userspace-writable pages to the Secure World; TEEGris copies command metadata into kernel circular buffers while sharing data pages; and Trusty copies message data into kernel-owned virtqueue buffers. The analysis demonstrates that QSEE’s shared-memory design allows the underlying buffer to be modified concurrently while it is being processed by the Secure World, resulting in a TrustZone crash and denial of service. The analysis additionally characterizes differences in the SELinux-exposed attack surface, with 75, 71, and 19 domains able to reach the relevant TEE interfaces in the rooted test con-figurations, as well as differences in locking granularity across the three implementations (global command-path, per-socket, and per-channel/per-device locking). These findings show that kernel-level data-transport and synchronization choices directly influence the classes of concurrency and memory-sharing defects exposed by each TEE architecture.