Safe Sharing of (Ethernet) Peripherals across enclaves
Description
Enclaves running in trusted execution environments might want to have direct control over peripherals such as network interface cards or accelerators. While making the device accessible to an enclave is often supported in hardware, sharing it between two enclaves comes with unique challenges. In particular, as devices are under the enclaves’ full control, no restrictions on their use of the devices can be enforced. This means that, e.g., one enclave can impersonate the network identity of another device by spooding its MAC and IP addresses or attempt to steal data from other enclaves’ computations from an accelerator device. Also, enclaves might attempt abuse DMA capabilities of devices to steal data from other enclaves. State-of-the-art solutions to this problem usually rely on trusted software that resets the device during context switches from one enclave to another to mitigate data leakage (CURE) in conjunction with memory access control or encryption, while use cases such as network policies for the enclaves usually require dedicating one interface port to each enclave.
This project aims at facilitating safe sharing of a network interface card between two mutually isolated enclaves. There are two components to this project: first, a mechanism for preventing abuse of the DMA capabilities of the Ethernet device is needed, ideally without having to rely on trusted software. Second, this needs to be complemented with enforcement of network access control. Ideally, the mechanism is compatible with legacy DMAs/Ethernet NICs.
Outline
- take microzone as basis: RISC-V TEE based on MPU and nanokernel
- alternatively: Northcape solves the isolation part of the project, but not the network policy enforcement
- add CURE-like access control to the system bus, based on allowed memory regions
- add an interface through which enclaves request DMA mappings: DMA mappings are tied to one enclave and define memoy buffer specified by enclave within its memory
- need one “virtual” DMA device per enclave: e.g., identified by AXI User / high-order address bits, added by CPU; one “virtual” DMA dev. has a descriptor queue for each zone (in the beginning of the project, can simulate this by multiplexing between different DMA devices)
- need a packet parser that maps incoming packets to enclave and verifies outgoing packets
- parser can interface with AXI-Stream between MAC core and DMA, in the beginning, pick a DMA using tdest/AXIS “switch”
- security model: DMA(s) cannot access buffer not set up for mapping, enclaves cannot abuse DMA for confused deputy, enclaves cannnot steal packets from other enclaves or impersonate other enclaves
Intended Scope
Master thesis
References / Extra Material
- Northcape paper: https://cispa.de/en/research/publications/79232-work-in-progress-northcape-embedded-real-time-capability-based-addressing
- CURE paper: https://www.usenix.org/system/files/sec21-bahmani.pdf
- Microzone RISC-V TEE: https://github.com/hex-five/multizone-sdk
Contact
