LDR: Secure and Efficient Linux Driver Runtime for Embedded TEE Systems

LDR: Secure and Efficient Linux Driver Runtime for Embedded TEE Systems

Speakers: Huaiyu Yan

Conference: NDSS Symposium

YouTube: https://www.youtube.com/watch?v=Hu-l_LKWfAw

Overview

This talk introduces the Linux Driver Runtime, or LDR, a novel execution environment designed to bring robust, secure, and efficient device driver support to Trusted Execution Environments (TEEs), particularly those leveraging ARM TrustZone. Given by Huaiyu Yan, the presentation addresses a critical limitation of compact TEE operating systems (OSes) like OP-TEE: their inherently limited and often inefficient device driver support. This deficiency significantly impedes the deployment of I/O-intensive secure services within the secure world, forcing developers to either painstakingly port complex Linux drivers (bloating the Trusted Computing Base, or TCB) or resort to performance-hindering emulation or frequent world switches.

LDR proposes an innovative hybrid approach. It functions as a sandbox within the secure world, intelligently reusing existing TEE OS library functions where possible, while selectively redirecting Linux kernel subsystem function calls to the normal world Linux kernel. Crucially, LDR enforces stringent security checks on all interactions and isolates vulnerable secure world (SW) drivers using ARM Domain Access Control (DAC) features, confining them within Isolated Execution Domains (IEDs). This meticulous design ensures that the TCB remains small, performance is comparable to native Linux drivers, and the secure OS is protected from potentially compromised SW drivers, thereby making TEEs far more practical for a wider range of secure, I/O-oriented applications in embedded systems.

The significance of LDR lies in its ability to bridge the gap between the rich driver ecosystem of Linux and the stringent security requirements of TEEs. By enabling the secure and efficient reuse of existing, well-maintained Linux drivers, LDR drastically reduces engineering effort, enhances application diversity within the secure world, and mitigates the security risks associated with driver vulnerabilities. The presented prototype, implemented on an NXP IMX6Q SABRE-SD board, demonstrates LDR's feasibility and effectiveness, showcasing negligible performance overheads and robust security against various attack vectors.

Background

▶ Watch: LDR: Secure, efficient Linux driver runtime for TEEs (0:00)

Trusted Execution Environments (TEEs), such as ARM TrustZone, and compact TEE operating systems like OP-TEE, have become fundamental components for protecting sensitive programs and data in modern embedded systems. They provide a hardware-isolated secure world for critical computations, cryptographic operations, and secret storage. However, a pervasive challenge for these compact TEE OSes is their severely restricted and often inefficient support for device drivers. This lack of robust I/O capabilities directly limits the types of secure services that can be deployed within the TEE, especially those requiring direct interaction with peripherals like sensors, cameras, or network interfaces.

Historically, addressing this driver gap has presented significant dilemmas. The most intuitive but problematic approach involves porting entire Linux drivers, along with their intricate dependencies, directly into the TEE OS. This method, while functional, leads to a substantial increase in the Trusted Computing Base (TCB) – the total amount of code and hardware that must be trusted for the system's security. A larger TCB inherently introduces more potential vulnerabilities, undermining the very compactness and security benefits that TEEs are designed to provide.

Existing alternative solutions have also faced considerable drawbacks. Driverlets, for instance, relies on emulation to execute drivers within the TEE. While this offers a degree of isolation, it inevitably leads to poor performance, making it unsuitable for I/O-intensive devices. Another approach, exemplified by MyTEE, involves keeping drivers in the normal world (NW) Linux kernel and allowing them to access secure peripherals via frequent world switches and hypercalls. This incurs heavy overhead, particularly for devices with high I/O demands, as demonstrated by an experimental sampling rate drop of 49.3% for an MMA8451 accelerometer driver compared to its default performance. Furthermore, redirecting all function calls to the NW Linux kernel raises significant security concerns, as a potentially untrusted NW OS could corrupt raw data by hooking I/O functions.

These limitations motivated the development of LDR, which aimed to address three primary goals:

1. Code Reuse: Maximizing the reuse of existing Linux driver code, especially low-layered functions for direct I/O, interrupt handling, and common utilities, to minimize engineering effort.
2. Security: Maintaining a small TCB by minimizing modifications to the secure OS and, crucially, isolating potentially large and vulnerable secure world (SW) drivers from the secure OS and each other.
3. Good Performance: Ensuring that SW drivers achieve performance comparable to their native Linux counterparts, without significant overheads.

To achieve these goals, LDR's design was informed by critical observations derived from analyzing the abstract structure of Linux drivers:

• Observation 1: Driver initialization and configuration functions (Init & Conf) that set up state variables are typically not needed at runtime. A secure and valid copy of the SW driver's state variable can be generated from an already initialized NW driver.
• Observation 2: Virtual File System (VFS) functions, which are service-oriented and handle user-space interactions, do not directly interact with peripherals. These functions, along with their dependencies, can be discarded, significantly reducing the driver's footprint and dependencies within the TEE.
• Observation 3: Driver dependency functions fall into two distinct classes: library functions (e.g., memory management, I/O operations) that are common across OSes, and Linux kernel subsystem functions (advanced driver management services specific to Linux). Library functions can often be directly supported by the secure OS by reusing existing capabilities, while Linux kernel subsystem functions necessitate redirection to the NW Linux kernel.

Before detailing LDR's design, it's important to understand its underlying assumptions and threat model:

• The secure OS is assumed to be trusted.
• Normal world programs, including the Linux kernel and NW drivers, are assumed to be trusted during the system boot phase. This allows for secure initialization of NW drivers and the generation of a legal NW state variable for the SW driver.
• However, after SW driver initialization, the entire normal world may be compromised and become malicious.
• SW drivers themselves may contain vulnerabilities (e.g., buffer overflows, ROP attacks). LDR's goal is to protect the secure OS from such attacks, maintain a small TCB, ensure code integrity and data privacy for each SW driver, and prevent untrusted SW drivers from corrupting other drivers' memory.
• LDR cannot ensure device availability; a malicious NW OS could cause denial-of-service by interfering with device clocks or power. This is considered outside the scope of LDR's core security guarantees.
• The underlying hardware is assumed to adhere to its specifications. Advanced hardware-oriented attacks, such as cache-based side channels or DMA attacks, are not within LDR's current scope.
• Crucially, devices can be configured as secure using the TrustZone Protection Controller (TZPC), making them exclusively accessible from the SW. This ensures the integrity and validity of raw data captured by the SW driver. Developers retain the flexibility to decide whether captured data remains SW-exclusive or is securely shared (e.g., encrypted or signed) with NW applications.

Key Findings

▶ Watch: LDR's three core goals and alternative design analysis (2:00)

LDR represents a significant advancement in enabling secure and efficient device driver support within ARM TrustZone-based TEEs. The key findings and contributions of this work are multifaceted:

1. Novel Hybrid Driver Execution Environment: LDR is the first to propose and implement a TEE driver execution environment that intelligently combines the reuse of existing TEE OS library functions with the selective redirection of Linux kernel subsystem functions to the normal world Linux kernel. This hybrid approach allows for maximal code reuse of existing Linux drivers while keeping the secure world footprint minimal.
2. Small TCB Expansion: Despite its comprehensive functionality, LDR introduces a remarkably small increase in the TCB. The total Lines of Code (LoC) for the OP-TEE OS increased by only 1.80% (4,947 lines added, 58 removed), and the binary size expanded by a mere 5.65% (from 557.1KB to 588.6KB). This demonstrates LDR's commitment to maintaining the compactness and security benefits of TEEs.
3. Comparable Performance to Native Linux: LDR drivers achieve performance metrics comparable to their native Linux counterparts, introducing negligible overheads for real-world applications. For instance, the MMA8451 accelerometer driver attained a sampling rate of 800.03 SR, precisely matching its default performance. Image capturing showed negligible latency overheads, and 480P video streaming incurred no speed penalty, with only a -2.43% downgrade for 720P streaming.
4. Robust Security Mechanisms: LDR comprehensively addresses security challenges associated with running potentially untrusted drivers in the secure world. It employs Isolated Execution Domains (IEDs) using ARM Domain Access Control (DAC) to isolate SW drivers from the secure OS and from each other. An IED gate mediates all driver interactions, enforcing Forward Control Flow Integrity (F-CFI) and sanitizing arguments/return values. Secure state variable maintenance schemes prevent sensitive information leakage to the normal world.
5. Effective Protection Against Attacks: LDR demonstrably protects the secure OS from untrusted SW drivers against memory corruption, code injection, and control flow hijacking attacks (including ROP attacks). It also secures SW drivers from malicious normal world attacks during both initialization and execution phases by protecting SW-exclusive fields and carefully synchronizing state variables.
6. Reduced Engineering Effort: By leveraging automatic function removal (e.g., using GCC's deadcode elimination) and providing a framework for reusing TEE OS functions and redirecting others, LDR significantly reduces the engineering effort required to adapt existing Linux drivers for TEEs compared to full porting or manual trimming.
7. Open-Source Availability: The LDR prototype is open-source, fostering further research and adoption in the security community.

In essence, LDR proves that it is possible to combine the vast utility of existing Linux drivers with the strong security guarantees of TEEs, overcoming the traditional trade-offs between performance, security, and development effort.

Technical Deep Dive

▶ Watch: Three key observations guiding LDR's design (3:20)

LDR's architecture and operation are meticulously designed to achieve its goals of code reuse, security, and performance. Its operation is divided into two main phases: the offline phase and the runtime phase.

Offline Phase: Twin Driver Generation and Dependency Support

The offline phase is crucial for preparing the Linux driver for execution within LDR. This involves generating a pair of twin drivers: a Normal World (NW) driver and a Secure World (SW) driver, from the original Linux driver.

1. SW Driver Generation (LDG):

• Based on Observations 1 and 2, unnecessary Init & Conf and VFS functions are automatically removed from the original Linux driver. This is achieved by leveraging GCC's deadcode elimination feature (-O1) during compilation. A Python script assists developers in identifying and commenting out function pointer assignments (e.g., for platform_driver, i2c_driver) which causes GCC to recursively exclude these functions and their callees from the final object file. Functions intended for deletion must be declared static.
• A new sw_init() function is added to register the SW driver with LDR's lightweight driver manager.
• Another new function, sw_probe(), is added. This function's role is to initialize device information fields of the SW driver's state variable by invoking secure OS memory mapping functions to acquire correct register addresses. Other subsystem data objects derived from the original Linux driver remain intact.

1. NW Driver Generation:

• The NW driver is also generated from the original Linux driver, with minor modifications.
• Extra operations are added to its init() and probe() functions to facilitate the secure passing of initialized subsystem data object fields to the SW driver.
• For data retrieval from the SW driver by NW applications, a Cross-World Procedure Call (CPC) mechanism is designed, involving the generation of NW and SW CPC stubs. The NW stub handles argument marshalling, while the SW stub unmarshals them and invokes the SW driver's data retrieval function.

1. Dependency Function Support: LDR then provides the necessary dependency functions for the SW driver based on Observation 3:

• Library Function Substitution: LDR reuses existing secure OS library functions for common utilities. These functions (e.g., memory management, basic I/O operations) provide identical functionalities to their Linux kernel counterparts. LDR wraps these functions to adapt their signatures to those declared by the Linux kernel. The prototype implements support for 39 existing OP-TEE OS or GCC library functions. Secure OS structures are often simpler (e.g., struct mutex in Linux is 20 bytes, in OP-TEE 12 bytes), but the SW driver, built with Linux KBuild, reserves sufficient memory.
• Linux Kernel Subsystem Function Redirection: Functions specific to advanced Linux kernel services, such as clock management and time delays, are redirected to the NW Linux kernel. This is achieved by generating RPC stubs that use the OP-TEE thread_rpc_cmd() interface. The prototype supports 7 such Linux kernel subsystem functions.
• LDR Driver Management Functions: The remaining 28 functions, specific to LDR's internal operation, are implemented from scratch. Overall, the symbol manager provides support for 74 dependency functions.

Runtime Phase: Cooperative Execution and Security Mechanisms

The runtime phase involves the cooperative execution of the twin drivers and the enforcement of LDR's robust security mechanisms.

1. Workflow of SW Driver Execution (Figure 4):

• A NW LDR client application initiates the process by passing the SW driver's ELF image to the SW driver loader via shared memory.
• The SW driver loader performs several critical tasks: it verifies the driver's digital signature, sets proper memory access attributes for its sections (code as R-X, data as RW-), resolves undefined symbols using the symbol manager, and relocates dependency function calls to their resolved addresses.
• The SW driver's sw_init() function is invoked to register driver information, including its state variable address, with the LDR driver manager.
• Concurrently, the NW driver is loaded and initialized in the NW Linux kernel.
• The NW driver then notifies the SW driver via CPC to invoke sw_probe(). This function is responsible for copying the initialized NW state variable to the SW driver's state variable. sw_probe() then initializes device information fields (e.g., register addresses) using secure OS functions.
• Once initialized, LDR leverages the TrustZone Protection Controller (TZPC) to configure the corresponding peripheral as a secure device, making it exclusively accessible from the secure world. SW I/O functions exclusively handle device interactions, and SW interrupt handlers manage device interrupts. To prevent NW Linux kernel interference, LDR dedicates one ARM core exclusively for secure interrupts, excluding it from NW usage.
• Other secure OS components (e.g., Trusted Applications) can directly access SW driver services by calling its exported I/O and utility functions.
• If NW applications require data from the SW driver, the CPC stubs are utilized, coordinated by the session manager.
• When the SW driver invokes a Linux kernel subsystem function, the call is transparently redirected to the NW LDR Linux kernel proxy, and the SW state variable is synchronized.

1. Driver Isolation (IED) (Figure 5): To protect the secure OS from potentially untrusted SW drivers, LDR creates an Isolated Execution Domain (IED) for each SW driver.

• IED Structure: LDR's memory layout is carefully structured. The secure OS occupies Domain 0/1, Trusted Applications (TAs) are in Domain 1, an IED gate resides in Domain 2, and multiple IEDs (Domains 3-15) are allocated for SW drivers. Each IED is provided with its own heap and stack.
• ARM DAC: LDR assigns unique domain numbers to each LDR component. IEDs are isolated from the secure OS and from other IEDs. The IED gate, however, is accessible to all. During execution, an SW driver can only access memory within its own IED and the IED gate.
• IED Gate Mediation: The IED gate is a critical component. When a SW driver calls a secure OS function, the IED gate intercepts the call, saves the IED context, and temporarily opens access to the secure OS. The secure OS is designed to serve only one IED at a time to prevent confused deputy attacks. Upon return, the gate restores the IED context and closes access to the secure OS.

1. Dependency Function Call Validation: The IED gate mediates every dependency function call, enforcing Forward Control Flow Integrity (F-CFI). During the loading phase, the SW driver loader links dependency calls to the IED gate's hook functions, meticulously recording (callsite, callee) mappings. The IED gate verifies these mappings at runtime, preventing calls from illegal callsites. Furthermore, SW driver code segments are marked R-X (read-execute), data segments RW- (read-write), and page tables reside within the secure OS, inaccessible to SW drivers. This design effectively prevents code injection and memory attribute manipulation attacks.

Secure State Variable Maintenance

Maintaining the integrity and privacy of driver state variables is paramount for security. LDR employs specific schemes for this:

1. SW-exclusive Field Labeling: LDR differentiates between shareable fields (subsystem data objects that can be safely passed to the NW) and SW-exclusive fields (sensitive information like device register mappings, which must remain strictly within the SW). Developers label SW-exclusive fields using a bitmap attached to the SW driver image, which LDR uses at runtime.
2. State Variable Initialization: The sw_init() function registers the SW driver's state variable address and the SW-exclusive bitmap with the LDR driver manager. The NW driver then initializes its state variable in the NW, and via CPC, copies the shareable parts to the SW driver. The sw_probe() function then redefines the SW-exclusive fields to reflect secure OS semantics.
3. State Variable Synchronization & Shadowing: For redirected kernel subsystem calls, a SW RPC stub leverages the SW-exclusive field bitmap. It synchronizes only the shareable fields between the SW and NW state variables, while shadowing SW-exclusive fields from the NW. This prevents sensitive SW-exclusive information from leaking to the NW. After the subsystem function returns, any modified NW shareable fields are synchronized back to the SW state variable, with the SW-exclusive fields remaining intact and protected.

Implementation Details

The LDR prototype is implemented based on OP-TEE OS 3.10.0. Key aspects of its implementation include:

• Automatic Function Removal: As mentioned, GCC's deadcode elimination (-O1) is used for VFS and Init & Conf functions, aided by a Python script.
• Dependency Function Support: The symbol manager supports 74 dependency functions in total.
• 39 are existing OP-TEE OS or GCC library functions, wrapped for signature adaptation.
• 7 are Linux kernel subsystem functions (e.g., clock management, time delay), redirected via OPTEE thread_rpc_cmd().
• 28 are LDR-specific driver management functions, implemented from scratch.
• A TEE_EXPORT_SYMBOL() macro is used to export secure OS functions, allowing the SW driver loader to resolve undefined symbols and link dependency calls to the IED gate's hook functions.

Demo / Proof of Concept

▶ Watch: LDR's security assumptions and threat model explained (4:00)

The LDR prototype was rigorously evaluated on an NXP IMX6Q SABRE-SD evaluation board, featuring 4 ARM Cortex-A9 cores and 1GB DRAM. The evaluation utilized a diverse set of on-board sensors and peripherals, including a barometer, magnetometer, accelerometer (MMA8451), ambient light sensor, thermal sensor, camera (OV5640), and an Image Processing Unit (IPU).

System Benchmarks

1. LMBench: Comparing LDR against vanilla Linux and the original OP-TEE OS (4 cores) as baselines, LDR introduced little overhead to most NW Linux services (Figure 6 in the paper). This is attributed to the LDR kernel subsystem call proxy not significantly impacting critical kernel code paths.
2. OPTEE xtest: The comprehensive xtest suite was run, and LDR passed all tests without failures. The results (Figure 7 in the paper) demonstrated that the dedication of one core for secure interrupts and LDR's internal mechanisms introduced negligible performance overhead to secure world execution.

Micro Benchmarks

1. Linux Subsystem Function Redirection: The latency of redirected Linux subsystem calls was measured for functions with 0 to 4 parameters. The average latency was a mere 11.14 µs, with the number of arguments having a negligible impact (Figure 8-(a)).
2. Cross-world Procedure Call (CPC) Mechanism: CPC latency was measured for varying parameters and data chunk sizes.

• Without parameters: 117.78 µs.
• With regular values: 140.02 µs.
• With data pointers: 140.29 µs.

The number or size of parameters had minimal influence, indicating negligible marshalling/unmarshalling overheads (Figure 8-(b)). Notably, CPC latency was approximately ten times that of a redirected subsystem function call, highlighting the efficiency of the latter.

Case Studies with Diverse Sensors

LDR's practical effectiveness was demonstrated through several real-world case studies:

1. Temperature Capturing (IMX6Q Thermal Sensor): The SW thermal driver successfully read SoC temperature data from the secure world, confirming proper functionality and data integrity.
2. Environmental Data Sampling (I2C-based sensors: Barometer, Magnetometer, Accelerometer, Ambient Light Sensor): LDR successfully supported these common I2C sensors. Data reading functions were exported, and a greedy polling method was employed.

• Performance: LDR SW drivers fully leveraged the devices' capabilities without compromising sampling rates. For example, the MMA8451 accelerometer achieved 800.03 SR, precisely matching its default performance (Table IV), significantly outperforming other secure I/O systems.

1. Image Capturing & Video Streaming (OV5640 Camera + IMX6Q IPU):

• The IMX6Q IPU driver was adapted into LDR, involving the discarding of VFS-related code, customization of init()/probe() for SW memory mapping and interrupt handling, and the dedication of one ARM core for secure interrupts. CPC stubs were created for interaction with the NW driver.
• Image Capturing: Using v4l2-ctl, LDR introduced negligible latency overheads compared to the original IPU driver for various resolutions (Figure 9).
• Video Streaming: Employing FFmpeg (RTP, x264) with ARM Neon features, LDR introduced no speed penalty for 480P streaming and only a -2.43% speed downgrade for 720P streaming (Table V). This indicates LDR's readiness for most video streaming tasks within a secure context.

Comparison with Other Secure I/O Systems

LDR's performance and security were benchmarked against two state-of-the-art secure I/O systems: Driverlets and MyTEE.

• LDR vs. Driverlets: Driverlets 13 utilizes a record-and-replay approach with an emulator, resulting in 11%-270% latency overhead for frame capturing. LDR, by running compiled driver binaries at native speed, showed almost no extra latency for frame capturing and supported smooth 24 FPS video streaming, which Driverlets cannot achieve due to heavy overhead. While Driverlets offers strong isolation by running entirely within the TEE, it lacks sophisticated libraries for data processing. LDR offers more application diversity by supporting SW-closed data processing and secure combination with NW applications (e.g., encrypted/signed data).
• LDR vs. MyTEE: MyTEE 16 keeps NW drivers in the NW Linux kernel, accessing secure peripherals via temporary supervised privilege escalation. LDR enables native TEE drivers in the SW. For high sampling rate devices like MMA8451, MyTEE achieved 610.19 SR, which is 23.73% lower than LDR's 800.03 SR (Table VI). This performance difference stems from MyTEE's I/O path involving two NW/SW world switches and two Linux kernel/hypervisor switches, incurring heavy overhead. LDR avoids these world switches on performance-critical I/O paths, leading to superior performance. Both systems require manual driver code analysis and modification, exclude drivers from the TCB, and protect drivers from NW attacks.

Defensive Implications

▶ Watch: Overview of LDR's offline phase: twin driver generation (4:50)

LDR's design incorporates robust security mechanisms that have significant defensive implications for TEE-based systems. These mechanisms aim to protect both the secure OS from untrusted SW drivers and the SW drivers themselves from malicious NW attacks.

Protecting Secure OS from Untrusted SW Drivers

The core principle here is to sandbox SW drivers, preventing them from compromising the integrity or confidentiality of the secure OS or other SW components.

• Memory Corruption: LDR leverages ARM Domain Access Control (DAC) to create Isolated Execution Domains (IEDs). A SW driver is strictly confined to its own IED and cannot access memory regions belonging to the secure OS, trusted applications, or other SW drivers. This hardware-enforced isolation effectively defeats memory corruption attacks, such as buffer overflows, that attempt to overwrite critical system data or code outside the driver's allocated memory. The CVE case study with a buffer overflow similar to CVE-2021-28972 demonstrated LDR's success in defeating such attacks by preventing the SW driver from accessing secure OS objects or other IEDs.
• Code Injection: SW driver data segments are marked as non-executable, and their code segments (.text) are non-writable. This prevents an attacker from injecting and executing malicious code within the driver's data regions. Furthermore, the page tables, which control memory access attributes, reside in the secure OS and are inaccessible to SW drivers, preventing attackers from manipulating memory attributes to bypass protection. The dependency function call validation scheme also denies any calls to memory attribute manipulation functions, reinforcing this defense.
• Control Flow Hijacking: LDR enforces Forward Control Flow Integrity (F-CFI) through its IED gate and the dependency function call validation scheme. During loading, the SW driver loader records legitimate (callsite, callee) mappings for all dependency calls. The IED gate verifies these mappings at runtime, ensuring that a SW driver can only invoke functions that are expected from a specific callsite. This prevents attackers from hijacking the control flow to arbitrary code, including Return-Oriented Programming (ROP) attacks. The IED gate itself is atomic and single-threaded, closing access to the secure OS before transferring control to the SW driver, preventing DACR manipulation ROP gadgets. The talk also suggests static code scanning to identify and remove such gadgets from SW driver binaries as an additional layer of defense. In the ROP attack CVE case study, attacks attempting to invoke secure OS functions or IED gate entries from illegal callsites were successfully thwarted by DAC and F-CFI.

Protecting SW Drivers from Normal World Attacks

While SW drivers are considered potentially vulnerable, LDR also implements mechanisms to protect them from a malicious normal world (NW) once the system is fully booted and the NW becomes untrusted.

• Driver Initialization Phase: During system boot, a trusted/secure boot process ensures that the Linux kernel and NW driver states are initially trusted and valid. By copying this trusted NW state variable, the SW driver obtains a legal and secure initial state, preventing malicious NW manipulation during setup.
• Driver Execution Phase:
• The SW state variable resides entirely within the secure world, and its SW-exclusive fields are explicitly protected by LDR's secure state variable maintenance mechanisms (Section IV-F). This prevents sensitive information like device register mappings from being exposed to the NW.
• For redirected Linux subsystem calls, LDR mitigates potential attack surfaces by carefully managing passed arguments, functions, and return values. The state variable synchronization and shadowing mechanism ensures that only necessary Linux kernel subsystem objects (shareable fields) are synchronized to the NW, while SW-exclusive data is shadowed, preventing sensitive driver data from leaking to the NW.
• Critically, the Linux subsystem function in the NW cannot directly access SW memory, thus protecting the SW driver's code integrity and data security from direct NW manipulation.
• LDR judiciously limits the number of redirected kernel subsystem calls to only 7 minimal functions (e.g., clock management, time delay), significantly reducing the attack surface compared to redirecting a broader set of kernel functionalities. While a malicious NW kernel could potentially cause denial-of-service (e.g., by closing a device's clock source), this is acknowledged as outside the current threat model and does not compromise the SW driver's code or data integrity.
• LDR's dependency function call validation mechanism can be extended to sanitize return values from the NW, recognizing and reacting to violations against Linux kernel subsystem function specifications.

General Defensive Recommendations

For defenders implementing or leveraging LDR, the implications are clear:

• Adopt LDR for Secure I/O: Integrate LDR into TEE-based systems to enable secure and efficient I/O services for sensitive applications.
• Utilize TZPC: Configure critical peripheral devices as secure using the TrustZone Protection Controller (TZPC) to ensure their exclusive accessibility from the secure world, safeguarding raw data integrity.
• Perform Static Code Scanning: Augment LDR's F-CFI with static analysis to identify and remove potential ROP gadgets from SW driver binaries, further hardening against control flow hijacking.
• Extend Sanitization: Continuously improve and extend the argument/return value sanitization mechanisms at the IED gate to cover new attack vectors or complex data structures.
• Secure Boot Chain: Ensure a robust secure boot chain is in place to guarantee the initial trustworthiness of the NW kernel and drivers, which LDR relies upon for initial state variable copying.

By combining hardware-enforced isolation, rigorous control flow checks, and careful state management, LDR provides a strong defensive posture for integrating complex device drivers into TEEs, greatly enhancing the security and utility of embedded systems.

Key Takeaways

• LDR enables secure and efficient reuse of existing Linux drivers within ARM TrustZone-based TEEs, addressing the critical lack of robust device driver support in compact TEE OSes like OP-TEE.
• It employs a novel hybrid approach, intelligently reusing existing TEE OS library functions and selectively redirecting Linux kernel subsystem calls to the normal world, while maintaining stringent security checks.
• LDR ensures a remarkably small TCB increase, with only a 1.80% increase in LoC and a 5.65% expansion in binary size for the OP-TEE OS, preserving the core security benefits of TEEs.
• Performance is comparable to native Linux drivers, introducing negligible overheads for real-world applications, as demonstrated by the MMA8451 accelerometer achieving 800.03 SR and smooth video streaming with minimal degradation.
• Robust security is achieved through hardware-enforced isolation using ARM Domain Access Control (DAC) to create Isolated Execution Domains (IEDs) for SW drivers, mediated by an IED gate that enforces Forward Control Flow Integrity (F-CFI) and sanitizes interactions.
• LDR effectively protects the secure OS from untrusted SW drivers (memory corruption, code injection, ROP attacks) and safeguards SW drivers from malicious normal world attacks (state variable protection, limited redirection of kernel calls).
• The project is open-source, providing a foundation for future research and practical adoption: https://github.com/SparkYHY/Linux-Driver-Runtime.

About the Speaker(s)

The talk was delivered by Huaiyu Yan. The provided transcript and metadata do not include specific titles or company affiliations for the speaker.