An overview of the Driverlet approach. A Driverlet uses concrete values to kickoff driver execution and records their interactions with devices. At run time, it replays the interactions but with parameterized, dynamic values.  
 

Overview

Driverlet is a novel approach to deriving device drivers for ARM TrustZone from mature Linux kernel drivers without rebuilding them from scratch. Its key idea is to intercept and record the driver/hardware interactions at register/DMA/IRQ interfaces using concrete values, and replay them with dynamic values inside TrustZone.

Why Driverlet

  • TrustZone apps need only basic, simple IOs : their current use cases in secure storage, trusted UI, and trusted perception call for only a small subset of basic IO functions such as block read/write, image capturing, and pixel rendering.

    A mature, full-fledged device driver is an overkill. TrustZone apps can be served by simple IO features.

  • Driver porting is impractical: besides simply copy-n-paste the driver code itself, the process invovles porting complex kernel dependencies, which span multiple kernel subsystems, e.g. kernel memory management, locking, scheduling.

    Instead of porting mature driver code, we selectively reuse driver interactions with device at software/hardware boundary, eschewing the heavy codebase.

  • [ Eurosys’22] "Minimum Viable Device Drivers for ARM TrustZone", Liwei Guo, and Felix Xiaozhu Lin, Proc. European Conference on Computer Systems, 2022.

Source code

  https://github.com/zaxguo/zaxguo.github.io/drvlet/drvlet.zip 

Build guide

The source code contains a minimal replayer and the MMC/USB driverlet sample. To simplify, the driverlet samples are included as standalone header files which can be compiled with (conceptually) any environment, e.g. baremetal. Note:

  • The replayer is assumed to work with OPTEE-OS so it needs support from OPTEE-OS for remapping device registers, etc.

  • The assumed platform is Rpi3 b+ and driverlet requires a platform-specific recording. So you need to record by yourself if you are using other platforms. See Section 9 of the paper for how to record on your platforms.

  • The impl uses polling for receiving input events from device, e.g. IRQs. So driverlets is blocking at this stage (sadly).

Directory structure of the source is listed as follows.

People

PhD students
Faculty and Researchers

License

All the pre-existing code and data are subject to their own licenses. All the userspace programs and kernel modules resulted from this project are under FreeBSD license .

Copyright (c) 2017-2019, Purdue University

All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

  1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

  2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

The views and conclusions contained in the software and documentation are those of the authors and should not be interpreted as representing official policies, either expressed or implied, of Purdue University.