Enclave Research

This repo gathers, categorizes, and compares knowledge on computation enclaves and trusted execution environments (TEEs). Note that different researchers and developers use the term "enclave" and "TEE" to mean similar things, I view this mostly as a difference of terminology for the purposes of this document.

This is a living document, contributions are highly welcome. Please help me if I have missed anything by making a pull request.

What are Enclaves?

In the early 2000's much research began to be devoted to dealing with the problem of a large, potentially untrustworthy software and hardware stack. While we normally expect supervisor and hypervisor software to isolate processes or VMs from each other, enclaves further expand this security model to also include isolation from some combination of either an OS, hypervisor, or even aspects of the physical hardware. Typically, enclaves are also coupled with an attestation mechanism, which allows a remote party to ensure an enclave is running securely.

Historically, the open source software community rightfully was extremely wary of the technologies used to build enclaves. The technologies were primarily aimed to be applied as a way to prevent users from modifying their own computers and to enable DRM and has been criticized as antithetical to the philosophy of open source software. Today the technology has found a more useful place in the realms of privacy sensitive applications and safety-critical systems; the former is interesting because it inverts the model of DRM--instead of vendors not trusting end users with their devices, now it's the user's who do not trust the cloud vendor's servers.

Known Primitives for Building Enclaves

Technology HW Arch Resources, Examples Key Mechanisms Attestation Mechanism Trusted Computing Base (TCB) VM Enclave Support Legacy App Support Availability Support Physical Defenses
Dedicated Processor Cores
Multicore
* Jailhouse, SecureCore Use dedicated cores or a coprocessor to isolate VMs or OSes. Use either nested paging or bus security to protect physical memory. Implementation defined. Likely would require a trusted hypervisor and bootloader.
  • proprietary hardware stack
  • hypervisor or firmware
IMP
Virtualization + Trusted Boot
Virt
* seKVM, pKVM, BlackBox Using a hardware root-of-trust, a trusted "lowvisor" is loaded and authenticated. This lowvisor provides isolation of VMs or applications from an untrusted host OS through nested paging. After trusted boot, lowvisor should generate attestation reports, though current implementations don't have this feature.
  • hardware stack
  • bootloader ROM
  • (typically) early Linux boot stages
  • Lowvisor
Intel Software Guard Extensions (SGX)
SGX
x86 Innovative Instructions... (McKeen et al.), Intel SGX Explained All-in-one hardware extension for enclave segments of processes. Added instructions to the ISA (EENTER, ECREATE, etc.). Enclave page cache (EPC) is encrypted before being written to DRAM. Hardware generates reports. Remote attestation uses Intel-provided provisioning and quoting enclaves.
  • proprietary hardware stack, new microcode
  • closed source Intel-provided enclaves
  • Intel SGX SDK Libraries
ME
Intel Trust Domain Extensions (TDX)
Virt
x86 All-in-one hardware extension for VM enclaves protected against an untrusted hypervisor and environment. Added instructions to the ISA (SEAMCALL, etc.). Total memory encryption (TKTME) is used with different keys for VM Enclaves. Hardware generates reports. Remote attestation uses Intel-provided provisioning and quoting enclaves.
  • proprietary hardware stack, new microcode
  • closed source Intel-provided enclaves
ME
AMD Secure Encrypted Virtualization (SEV), SEV Encrypted State (SEV-ES), SEV Secure Nested Paging (SEV-SNP)
Virt
x86 Terra, Flicker, TrustVisor All-in-one hardware extension for VM enclaves protected against an untrusted hypervisor and environment. Adds a security coprocessor and additional ISA instructions for managing VM memory. MMU is extended with memory encryption engine which uses per-VM keys. Register states are encrypted on context switches. Integrity is enforced through a reverse map table. Coprocessor generates signed report. Root of trust system used with AMD root CA at the beginning of the chain.
  • proprietary hardware stack, new microcode
  • closed source coprocessor firmware
ME
ARM TrustZone + Bus Security
TrustZone
ARMv7, ARMv8 Pinto Survey, ARM Whitepaper Hardware extension dividing processor into two security worlds. Additional EL3 privilege level added, and SMC instruction to call into EL3 mode. Programmable EL3 firmware (a.k.a. the Secure Monitor) and Secure world OS used to create enclaves/TEEs. Vendors must implement bus security, e.g. a TrustZone Address Space Controller (TZASC). Secure world may use interrupts to preempt normal world, and many system use a real-time OS as the secure-world OS. Some research efforts have implemented remote attestation.
  • proprietary hardware stack
  • firmware, e.g. ARM Trusted Firmware
  • Secure world OS/hypervisor
IMP
ARM Confidential Compute Architecture (CCA)
TrustZone
ARMv9 Li et al. Hardware extension building on ARM TrustZone. Processor is further divided to add a Realm world. Programmable EL3 Secure Monitor context switches between the Normal world, Secure world, and Realm world. Realm world has a programmable (and verified) EL2 Realm Management Monitor (RMM) hypervisor to switch between realms. MMU is extended to support a Granule Partition Table (GPT) to protect physical memory. No CCA specific mechanisms available yet. Likely implementations will attest Realm VM enclaves using a chain of trust from the Secure Monitor to RMM.
  • proprietary hardware stack
  • EL3 firmware (Formally Verified)
  • RMM (Formally Verified)
IMP
Capability Hardware Enhanced
RISC Instructions (CHERI)
* Introduction to CHERI, Project Oak Enclave Generic ISA extension to add architectural capabilities. Memory accesses must be authorized using a capability held in a capability register file. Capabilities define the bounds a pointer may access and the permissions it may access. Valid pointers can only be derived from other pointers. A number of kernels and hypervisors have been derived from this technology. No known mechanisms.
  • any proprietary hardware, some formal verification has been done on the CHERI spec.
  • compiler correctness for generating tight pointer bounds (least privilege)
  • correctness (outside of memory safety) of the hypervisor or OS
RISC-V Machine Mode (M-Mode)
RISC-V
RISC-V RISC-V ISA Manual, Keystone RISC-V's physical memory protection (PMP) feature can create regions of isolated enclave memory. M-Mode can context switch between enclaves. Some research efforts have implemented remote attestation.
  • hardware stack, potentially formally verified
  • M-Mode software
IMP
Pure Software Approaches
Software
* SWATT, Pioneer, Virtual Ghost, RedLeaf Language-based isolation and software-fault isolation techniques, including control-flow integrity (CFI), type safety, proof-carrying code (PCC), typed assembly (TAL), or formal verification may be useful for creating enclaves and some of these techniques have been explored in the past. Older works used nearly-perfectly optimized hashing functions to establish a root of trust based on computation time, requiring only software modifications. Timing-based software root of trust. Project specific, but often the compiler is part of the TCB.
Fully Homomorphic Encryption & Verifiable Computation * Non-Interactive Verifiable Computing, Pinocchio Fully Homomorphic encryption schemes allow computation on encrypted data while the agent performing the computation has no knowledge of the instructions or data being performed. Naturally this provides a similar protection as hardware-based enclave schemes. Attestation is not needed, rather, a probabilistically checkable proof (PCP) is generated which can check that the computation was correctly performed. Likely a circuit-garbling compiler will be trusted. ME
Custom Processor Design/FPGA
Hardware
* Maene Survey 2018 Outside of industry-provided hardware primitives, a number of academic proposals have demonstrated major and minor changes to hardware architectures to support enclave-like security. Implementation specific Implementation specific ME

Key
ME Memory encryption. Bus snooping may reveal access patterns unless ORAM is used.
IMP Implementation defined feature.
Support is unclear or unresearched.

Enclave Technical Works

This table documents major technical contributions for enclave research in semi-chronological order. Incremental works by similar authors are grouped together as much as possible. C.I.A. in this table represent Confidentiality, Availability, and Integrity security properties respectively. RA indicates that remote attestation support is available, and P indicates that physical attacks like cold boot attacks and bus sniffing is protected against. MA stands for microarchitectural side channel attacks, like Spectre and Meltdown.

`
Year(s) Work Venue(s) Domain Target Enclave Key Technical Idea(s) C I A RA P MA IO Support Legacy
2003 AEGIS ICS Hardware Process Processor is extended to provide either memory integrity or memory encryption and integrity for enclave processes. Integrity is achieved through Merkle hash trees.
2003 Terra SOSP Virt VM Uses a small trusted VMM to launch enclave VMs after a trusted boot.
2004 SWATT IEEE S&P Software Process Using a nearly perfectly optimized memory-content verification procedure, which pseudo-randomly traverses memory can computes the checksum of memory many times, a remote party can attest that a small embedded device's code has not been modified. Any changes to the function would be detectable due to the extra time it would cause to the computation.
2005 Pioneer SOSP Software Process Using a nearly perfectly optimized checksum function, this paper demonstrates how to build a pure software root of trust that allows a remote dispatcher to detect adversarial modifications by checking the execution time of the checksum.
2006 Proxos OSDI Virt Process Design of a split OS enclave architecture using virtualization. One private/secure OS and one untrusted OS. Designs a language to allow an application to configure what system calls and paths in the filesystem are to be routed to what OS. Ported
2006 Nizza EuroSys Virt Process Paravirtualizes L4Linux as a L4 process. Runs security sensitive applications (enclaves) as L4 tasks.
2008 Overshadow, (follow up) ASPLOS, HotSec Virt Process Implements new concept of cloaking and multi-shadowing where each page of an enclave has an encrypted and unencrypted copy. The encrypted view is given to the untrusted kernel, and the unencrypted view is given to the user. Writes from kernel to encrypted page trigger decryption, and writes from enclave to plaintext trigger encryption. Provides a shim for communicating with the trusted VMM from the enclave, and handles many system calls. Follow up work discusses many of the problems with needing to trust the OS for system calls, and possible solutions.
2008 SP3 VEE Virt Process Similar to Overshadow, a hypervisor uses a shadowed page table with encrypted and unencrypted copies of data selected dynamically depending on the executing security domain (user enclave or OS). Defines algorithm for lazy encryption and decryption to optimize performance. Hypervisor encrypts enclave register state on exception or interrupt and provides the OS an interface for switching into enclaves in order to decrypt that state.
2009 Mobile Trusted Modules CCSW/STC TrustZone Process Presents essential techniques for using the TrustZone to run a secure and non-secure Linux instance, interrupt sharing, secure boot. Concept of a TrustZone-Assisted hypervisor is presented where the secure world and Monitor/EL3 mode is used as a hypervisor for the normal world.
2009 Flicker EuroSys Virt Segment Uses AMD SEV or Intel TXT to execute a piece of app logic instead of a VM. On SKINIT/SENTER instruction, a loader saves the state of the OS, sets up a small execution environment for the application and jumps to ring 3. A TPM platform control register is updated up on completion to contain the attestation quote.
2010 Bastion HPCA Hardware Virt Segment Hardware extensions supporting memory encryption and cache/register changes to track enclave memory. A new hypervisor is used to provide hypercalls which launch a small enclave segment/module process. Seems similar to AMD SEV + Flicker.
2010 TrustVisor IEEE S&P Virt Segment Improves on Flicker by providing TMP services in software and only using hardware TPM functions when necessary. Removing the need to interact with a hardware TPM for basic enclave operations leads to a great performance improvement.
2010 SPM (Strackx et. al.) SecureComm Hardware Segment Early hardware design for a memory protection system for "self-protecting modules" (SPMs) based on the address in the program counter (PC) register. Modules have confidentiality and integrity from the kernel in terms of memory access, but interrupt register swapping and a number of other issues are future work.
2010-2013 SafeG OSPERT, SWEST13, TRUST TrustZone Virt Process Uses the ARM TrustZone to run a real-time OS. Interrupts are divided so the Secure world can preempt and schedule the normal world. Physical memory and devices are divided and isolated using TZASC. Real-time scheduler is aware of normal world scheduler and visa versa, they can collaborate to integrate scheduling. Divided RT
2011 CloudVisor SOSP Virt VM Deprivileges the Xen VMM into a guest VM, and runs Cloudvisor in host mode. Guests are run using nested virtualization; their page tables are stored in the VMM guest's address space, but in read-only mode. CloudVisor tracks page ownership and unmaps guest pages from the VMM. Cloudvisor interposes on VMEnter, VMExit and VMRead/VMWrite instructions as well as IOMMU faults. Disk IO is encrypted transparently. Some state is leaked to Xen to support IO. Partial
2012 SMART NDSS Hardware Attest Only Demonstrates very minimal hardware extensions needed in order to establish a dynamic root of trust for an enclave. Using a challenge-response protocol, a remote verifier can dynamically attest a region of memory. The key needed create the response must be stored in a special ROM which is only readable by the SMART ROM code in charge of generating a response. Must be paired with other approaches to construct full enclaves. Timing
2012 Masti et. al. ACSAC Hardware Process Implements an application aware memory protection unit, peripheral bus manager, scheduler, and atomicity monitors in hardware to support real-time enclaves. To prevent preemption at incorrect times, a new instruction is introduced to allow an application to mask interrupts for a bounded number of instructions. Sharing
2013 SecureCore RTAS Virt Multicore Process Runs a safety critical application on a dedicated core with it's own OS to provide availability for safety-critical processes. Uses nested paging and a custom hypervisor to provide memory and device isolation and communication. Divided
2013 SASP ICCVE TrustZone Virt Process Designs support for shared devices using paravirtualization concepts applied to a TrustZone-assisted hypervisor. Para RT
2013 Sancus Usenix Security Hardware A hardware architecture for enclaves on embedded devices using a PC-based memory access control scheme from SPM (Strackx et. al.) and dynamic root-of-trust from SMART. Provides an architecture for remote attestation of enclaves. Enclaves cannot be interrupted, and have dedicated entry points to prevent ROP attacks. Provides a scheme for interaction among enclaves via linking or IPC; the caller can authenticate the callee using a nonce and MAC at link time. For IPC communication a (transparent) MAC-based handshake is proposed.
2013 InkTag ASPLOS Virt Process Supports semi-unmodified Linux applications as enclaves with a subset of system call functionality. The InkTag hypervisor owns the real page tables for an enclave, and checks the OS's changes to its copies. The OS is allowed to change the page tables if it can produce a token which the enclave provided to it. This aims to capture the intent of the enclave to give access control to the page tables and prevent Iago attacks. Semi
2014 Virtual Ghost ASPLOS Software Process The entire FreeBSD kernel is recompiled with a modified LLVM compiler which prevents binary code injection and ROP attacks by enforcing control-flow integrity (following up on previous work on "Secure Virtual Architectures"). This software isolation instrumentation is then used to implement ghost memory, which the OS cannot read or write, this is used to implement enclaves. The OS effectively needs to be ported to a new architecture to support the new compiler's handling of low-level state manipulation.
2014 MiniBox Usenix ATC Virt Process Extends TrustVisor to support the execution of more rich applications (including legacy applications like OpenSSL) using Google's Native Client (NaCl). Ported
2014 TrustLite EuroSys Hardware Process Hardware is proposed for small embedded devices without virtualization to extend the memory protection unit's (MPU) protection to include a column for code location. On a memory access, the table is indexed using the IP into the code column to determine whether the target address is accessible. Additional hardware is also needed to save register state of enclaves so leakage doesn't occur on interrupts. Peripheral/IO access is provided by via MMIO access from enclaves, protected by the MPU. Scheduling is performed by the untrusted OS. Divided
2014 Trusted Language Runtime (TLR) ASPLOS TrustZone Segment Architecture for running managed .NET code in TrustZone. Secure world implements interpreter, type-system enforcer, and garbage collector. Uses proxy paradigm to perform RPC calls across worlds. Partial
2015 SeCReT NDSS TrustZoneSoftware Segment Shows how a Linux process can do computation with a secret key that linux cannot read. When process tries to read the key it traps into EL3, which checks the integrity of the user process's CFG, the Link Register, and the integrity of the Linux vector trampolines, etc. If safe the key is loaded into the user process, and all traps are routed to EL3. Upon a second trap the key is scrubbed from the cache and memory.
2015 TrustICE ICDCS TrustZone Process Simple approach to managing the TZASC on a system where only one Secure world memory range is configurable. Unfortunately, performance scales poorly with many enclaves due to copying.
2015 Haven OSDI SGX Process Uses a library OS to run unmodified Linux binaries on SGX. ME Recompile
2015 TyTAN DAC Hardware Process TyTAN extends the EA-MPU design from TrustLite to implement an open system which can support dynamic loading of enclaves on FreeRTOS. Synchronous and Asynchronous secure IPC is also supported between enclaves using shared memory and a proxy to assist with authentication. Enclaves are protected from the OS in terms of spatial isolation, but are still scheduled by the OS, so lack availability guarantees. Divided
2015 Soteria ACSAC Hardware Process Extends Sancus to support offline confidential code loading in hardware. The design provides additional modules which are capable of decrypting other modules based on keys provided by the hardware.
2016 SCONE OSDI SGX Container Run unmodified Linux applications in a container in SGX. A way of performing system calls asynchronously is presented. ME Recompile
2016 Sanctum Usenix Security Hardware
RISC-V
Segment An architecture for running enclaves with minimally invasive hardware changes. Provides a transparent implementation on RISC-V. Addresses previous cache side channel attacks in SGX by using a page coloring scheme to partition the cache. ME PC
2016 CaSE IEEE S&P TrustZone Process Supports running TrustZone applications purely in the cache and encrypting their data before being written to memory. NS flag is used to divide the cache and provide isolation on chip. Cache lines are loaded then locked into place, code cache lines must be clear to PoU (usually the LLC). ME
2016 OSP Hypervisor Usenix ATC TrustZoneVirt Process Limits privilege escalation potential for enclaves by running them in the Normal world. While the Normal world is executing, TZASC protects enclave memory and single-level paging is used. While enclave is executing nested paging protects Normal and Secure world OSes. This is a performance optimization limiting the need for nested paging.
2016 PrivateZone TDSC TrustZoneVirt Segment Similar to OSP Hypervisor, prevents potential for enclave privilege escalation by running enclaves in the Normal world. Difference is that the TZASC isn't dynamically adjusted and the normal world and enclaves always use nested page tables to enforce isolation. Android applications can be split into an enclave and non-enclave segment.
2017 LTZVisor, LTZVisor-AMP ECRTS, IECON TrustZone VM Similar TZ-Assisted Hypervisor architecture to SafeG. Improves by implementing VirtIO like interface and supporting a multicore ARMv8 platform. Divided RT
2017 ╬╝RTZVisor Electronics TrustZone VM A design for a TZ-Assisted Hypervisor which is able to run multiple guest OSes. The TZASC is leveraged to isolate the currently running OS in the Normal World from the other OSes which are partitioned into the Secure World. Upon VM switch, the TZASC is configured to partition the memory so a different OS is in the Normal world. The cache and TLB must be completely flushed on switch. Secure devices are managed by EL3. Divided
2017 Graphene-SGX Usenix ATC SGX Process Group Implements a library OS for Unmodified SGX applications. Achieves better performance than many other SGX designs showing feasibility of Library OS implementations. ME Partial
2017 TrustShadow MobiSys TrustZone Process Runs unmodified Linux applications in the secure world. System calls are forwarded by replaying the call in the vector table. Arguments are copied to the Normal world. Page tables are mostly managed by the secure world, table updates are communicated from Normal to Secure.
2017 Komodo SOSP TrustZone Segment Implements a formally verified (using Dafny) SGX-like enclave interface using the ARM TrustZone.
2017 vTZ Usenix Security TrustZoneVirt Process Supports virtualization of the ARM TrustZone and constrained enclave behaviors for better overall security. Ensures that the Normal-world Hypervisor cannot modify its own page tables by replacing all translation and exception configuring MRS/MSR instructions in its code and making the page tables and code sections and vector tables read only. The Secure world updates the page tables on behalf of the hypervisor. A region of Normal-world memory is then protected for use of creating virtualized enclaves. All exceptions are routed through the secure world by injecting SMCs into the vector table; this is done to support switching to and from enclaves (in addition to also replacing ERETs with SMCs). Enclaves must run to completion and interrupts are disabled during their execution, preventing them from DoSing the normal world.
2018 RT-Trust GPCE TrustZone Segment Presents an automated way of splitting an real-time application into an enclave and non-enclave segments for TrustZone execution. Refactored
2018 Graviton OSDI Hardware GPU Context Presents an architecture for enclaves on a GPU with minimal hardware extensions. Commands for setting up GPU kernels are encrypted and routed through the command processor instead of allowing arbitrary CPU modification of GPU page tables over MMIO. The GPU is extended to support a burned-in private attestation key for creating secure communication channels, and it is updated to support protected and hidden on-chip memory. ME GPU
2019 SecTEE CCS TrustZone Segment Implements an TrustZone enclave architecture which is resistant to side channel attacks and has a remote attestation scheme. Decrypts pages before they go off the SoC to protect against some physical attacks. ME PC
2019 HypSec Usenix Security Virt VM Similar to Cloudvisor, this paper splits the KVM hypervisor into two parts: a lowvisor and highvisor. Highvisor is deprivileged and run like a VM with nested paging. Lowvisor provides an API for interacting with creating and guests. Avoids CloudVisor's nested virtualization by introducing shadow nested page tables for the guest VMs, which are managed by the highvisor and shadowed by the lowvisor. Highvisor performs device emulation and IO paravirtualization.
2019 Ginseng NDSS Software
Virt
Segment C/C++ language and compiler are extended to be able to mark variables and functions as sensitive. Compiler propagates sensitive tag, disallows sensitive registers to state spill onto the stack. When state must be saved, compiler adds SMC or HVC calls to invoke a service to encrypt and save the variables onto a secure stack. OS's ability to control page tables removed and an API is provided to support/check page table updates. While secrets are in play/in registers, all exceptions route to EL3 by updating the EL1 vector tables. Reg
2019 Sanctuary NDSS TrustZone
Multicore
Process Reduces TCB of a TrustZone-based enclave by running it in the Normal world, at the cost of core utilization. Uses the TZC-400 bus controller's ability to distinguish the originating core's identity to create additional privilege levels on a per-core basis. This is used to allow enclaves to run isolated on dedicated cores while still executing in the Normal world. OP-TEE's Linux runtime is adapted to use the hotplugging feature of the Linux kernel to turn off a core before sending the enclave to be launched on that core via the EL3 firmware. Cache side channel resilience is automatic for the L1 (inner or core-local) cache, the L2 (outer or shared) cache could either be disabled; however, for ARMv8 data caches may not need this protection. Cache
2019 TEEv VEE TrustZoneVirt VM Prevents security risk of a vulnerable/malicious secure-world OS. Virtualizes a Secure-world OS without needing virtualization hardware. The Secure-world OS binary is scanned for any privileged instructions like MRS/MSR instructions, and they are replaced with calls into special gates which perform a trap. The S-EL1 page tables are setup for the Secure-world OS to prevent access to any other memory, including other Secure-world OSes or the Normal World. By locking the TLB entries for the gates globally across all ASIDs, the gate can safely swap the page tables from the Secure-world OS to the TEEv hypervisor. A few different IO paradigms are supported. Divided
2020 Keystone EuroSys RISC-V Process Demonstrates how to use RISC-V's machine mode and phyiscal memory protection (PMP) system to create enclaves. ME PC
2020 Occlum ASPLOS SGX Process Group Supports better performance for SGX enclaves by running multiple processes within the same enclave with a custom LibOS. Creates process SFI boundaries using Intel MPX instructions to instrument memory access protections, and instruments labels and jumps with checks to ensure CFI. Later versions (Next-Gen Occlum), improve system call performance by using Rust async/await and io_uring-based optimizations (talk) (website). ME
2021 TwinVisor SOSP TrustZone VM Runs a TrustZone Secure world VM via S-EL2. Secure world hypervisor lets EL1 manage page tables, and checks and syncs them with secure world. Develops a cooperative dynamic memory split.
2021 CHANCEL NDSS SGX SFI Client Using a single SGX enclave, multiple distrusting client applications can be concurrently executed, protected via SFI instrumentation. LLVM adds memory isolation instrumentation to memory access and control-flow instructions, during the secure load process, the binary is disassembled to verify that the instrumentation is valid. Threads can communicate via shared memory regions, mediated through the SecureLayer runtime provided by CHANCEL. ME Recompile
2021 Aion CCS Hardware Process Builds upon Sancus to support enclaves on an open embedded system, adding an exception engine in hardware which allows both enclaves and non-enclaves to be preempted. A scheduler enclave is used to allow availability guarantees while preventing the OS from arbitrarily changing the scheduling; this enclave is given sole control of the interrupts. Ported
2021 RealSWATT CCS Software
Multicore
Attest Only Dedicates a processor core to continuously run a software-based attestation scheme. The concerns for software-based attestation around timing delays in the network are circumvented by running the attestation scheme continuously; the prover sends a new nonce before receiving the current attestation result. Variations in transmission time must be significantly shorter than the time required for attestation. The hash function is selected to not allow a multicore attacker computational advantages to parallelization. Attestation covers all code and data sections.
2021 CURE Usenix Security Hardware
RISC-V
Process
VM
Supports both user-space and kernel-space (including whole VM) enclaves with some hardware modifications. The cache is partitioned according to enclave ids, and the memory bus is updated to support protection for enclaves using peripheral devices and DMA. A machine-mode Security Monitor (SM) manages both types of enclaves. User space enclaves have a small library to support system calls. Devices requested by a kernel-level enclave are unmounted and the non-enclave OS turns off the target core for the kernel enclave using Linux hotplugging, the SM boots the kernel enclave on that core. Cache Divided Recompile
2021 ERTOS CARRV RISC-V Process Runs an instance of FreeRTOS as an enclave in the Keystone framework. Machine mode timer interrupts are forwarded to the FreeRTOS enclave. Implements synchronous message passing and asynchronous message passing over shared memory (with some overhead due to the time to register with the PMP).
2022 GAROTA Usenix Security Hardware Process Designs and formally verifies a system allowing interrupts to be configured only by trusted software. The hardware is configured to use a PC-based memory integrity scheme, i.e. only writes from the trusted software address range can update the protected memory. Interrupt configurations are also only allowed by trusted software. Availability is supported by configuring a interrupt to launch an interrupt handler in the protected memory. Formal verification is done using model checking with Linear Temporal Logic (LTL) specifications, Verilog and RTL hardware designs are converted and checked against the LTL specs.
2022 RT-TEE IEEE S&P TrustZone Process Supports sharing devices between worlds using by replacing Normal world writes to their MMIO region with SMC calls. Policy of device usage is enforced by pattern matching the device access against a set of known access patterns. Implements availability in a similar way as SafeG and LTZVisor. Sharing
2022 BlackBox OSDI Virt Container Similar to Flicker and TrustVisor, uses nested paging to isolate container enclaves. Container Security Monitor (CSM) at EL2 provides interface for OS to create container enclaves and manage page tables. All exceptions and interrupts pass through CSM by forcing the EL1 vector tables to jump to CSM. Supports unmodified applications by forwarding system calls and requiring collaboration between OS and CSM.
2022 HyperEnclave Usenix ATC Virt Segment Runs (mostly) unmodified SGX applications using a hypervisor with nested paging. ME
2022 StrongBox CCS TrustZone GPU Task Supports enclave usage of a GPU on an ARM SoC shared CPU/GPU memory model. Secure GPU tasks are submitted to the GPU driver in the normal world in ciphertext form, when the task is prepared to be scheduled, the GPU driver is updated to issue an SMC to invoke the EL3 StrongBox runtime. The runtime decrpyts the data and kernel code and submits the task to the GPU. At the same time the runtime also disables access to GPU MMIO and IRQs via nested paging and changing the interrupt controller configuration. Sharing Ported
2023 MyTEE NDSS TrustZone Virt Process Implements TEE/Enclave support for ARM devices that don't have bus security mechanisms like the TZASC, TZMA, and TZPC. An EL3 active integrity monitor maintains control of the EL2 state-2 page tables, creating a small hypervisor service for trapping, filtering, and emulating DMA requests and handling other MMIO requests. Enclaves route device IO through the untrusted kernel via a proxy. The kernel invokes hypercalls to escalate its privilege when it wants to access a privileged device. The hypercalls perform the MMIO on behalf of the kernel, in a device-dependent way, storing results in a EL2 secure buffer to be read by the enclave. Sharing
This table is a work in progress. Recent entries to be added soon.