1 Background

Many situations use secure execution environments, such as touch id, face id, DRM video stream and mobile payments.

Nowadays, Trust Execution Environments like TrustZone are pervasively employed to protect security sensitive programs and data from various attacks. Most compact TEE-OSes, such as OP-TEE, only provide basic core APIs, they often have poor device driver support.

A lot of research aims to provide device driver support due to the absence of sophisticated driver support inside TEEs. Among the existing research methods, some use porting existing kernel driver code, some simulate driver execution, and some implement it by completely calliing kernel functions. In those approaches, porting existing driver code is a non-trivival work, simulating driver execution may have negtive impact on performance and redirecting all function calls to Linux kernel may downgrade performance and cause security issue.

LDR is designed to provide a sandbox environment to address the engineering-effort, performance and security issues mentioned above.

2 Design

This design mainly solves two problems, reusing existing Linux Driver codes and providing an isolated exection environment.

2.1 Twin Driver

To overcome the engineering-effort caused by porting codes, the paper presents twin driver, namely called NW driver and SW driver.

The SW driver is generated by recognizing and removing unnecessary functions from the original driver.

The NW driver is also generated from the original Linux driver with minor modifications to initialize the state variables for the SW driver and provide data retrieval interfaces to NW applications if needed.

2.2 Driver Isolation

We don’t trust any third-part driver, so LDR confines each SW driver inside an isolated execution environment in order to prevent a SW driver from corrupting the secure OS memory as well as other driver’s memory regions. What’s more, LDR intercepts each secure OS function invocation issued by SW drivers, and checks its validity.

LDR creates an isolated execution domain(IED) for each SW driver, which benefits from ARM’s Domain Access Control. A typical LDR memory layout consists of parts shown in the figure as follows.

Domain 0 is for secure OS, domain 1 is for trust application, domain 2 is for IED gate and domain 3 to 15 are for IEDs(ARM only supports 16 domains).

IDE gate’s purpose is to mediate each dependency function call and verify all dependency function calls issued by SW drivers.

2.3 Secure State Variable Maintenace

The state is an important part of all devices. State variable exchages between NW and SW during the SW driver initalization and Linux kernel subsystem call redirection. In order to protect SW state variables, we need to differentiate which fields are allowed to be passed to the NW.

We refer to the subsystem data object fields as shareable fields while the remaining fields as SW-exclusive fields.

3 Limitations

As mentioned in this paper, this paperwork has the following limits:

• Limited library functions
• No work-queue & kernel thread fucntion
• Manally analyse Init & Configure functions and VFS code, even use GCC deadcode elimination feature

References

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