Stockade: Hardware-Enforced Sandboxing

• Stockade is an extended enclave model that enforces bi-directional memory isolation by assigning each enclave a defined ELRANGE, ensuring no unauthorized memory access.
• The architecture incorporates a trusted syscall monitor enclave that mediates system calls through attested policy enforcement to mitigate Iago attacks.
• It introduces hardware-assisted inter-enclave memory sharing using ESADD and ESACCEPT instructions, enabling efficient and secure communication between paired enclaves.

Stockade is an extended enclave model designed to provide hardware-hardened distributed trusted sandboxes in cloud and multi-tenant environments. It directly addresses the limitations of traditional hardware-based trusted execution environments (TEEs), such as Intel SGX, by supporting bi-directional isolation and secure memory sharing between mutually distrustful software modules. Stockade introduces three core innovations: extended hardware-based memory isolation, an attested syscall monitor enclave, and efficient hardware-protected memory sharing, facilitating robust two-way sandboxing and inter-enclave cooperation with minimal hardware modifications (Park et al., 2021).

1. Extended Hardware-Based Memory Isolation

Stockade generalizes the enclave memory protections of Intel SGX by enforcing strict bi-directional sandboxing. In SGX, an enclave can access enclave memory, but Stockade further ensures that a bi-enclave can neither read nor write any location outside its designated address interval, even when mapped by the host or other enclaves.

• Enclave Linear Range (ELRANGE): Each enclave E is assigned a contiguous virtual interval during EINIT: $\mathrm{ELRANGE}(E) = [L_E, U_E)$ All memory accesses by the enclave are restricted within this region.
• TLB-Miss Validation: On every TLB miss, the CPU performs a page-table walk and a check against the Extended Page Cache Map (EPCM). Stockade adds an extra check: $t^{th}$1 This guarantees $$\forall t: (\mathrm{mode}_t = \text{bi-enclave}) \implies (L_E \leq \mathrm{VA}_t < U_E)$$ for the address of the $t^{th}$ access.
• Control-Flow Confinement: The EEXIT instruction is disabled in bi-enclaves, prohibiting synchronous exits. Asynchronous exits (AEX) still occur for interrupts/faults but do not yield control to untrusted code, eliminating enclave escapes.

This dual-direction isolation ensures mutual protection: the bi-enclave cannot affect the system outside its bounds, nor can the system interfere with it except through asynchronous events.

2. Trusted Monitor Enclave Architecture

System-call mediation in Stockade is performed by a neutral, hardware-protected monitor enclave. All syscall requests from bi-enclaves are funneled to the monitor enclave, which is isolated from both the host OS and the bi-enclaves.

• Policy Loading & Attestation: At startup, the monitor enclave obtains a syscall-filter policy file from untrusted storage, computes a cryptographic digest $H(\text{policy})$, and returns it to both the OS and bi-enclave for attestation.
• Marshalling & Dispatch: All syscall invocations are serialized and written to a shared EPC page. The monitor enclave validates requests against the policy, performing actions like ALLOW, LOG, NOTIFY, KILL, or TRAP. Syscall results are deserialized and returned only after validation of legal ranges to prevent Iago attacks.
• Return-Value Validation: To prevent exploits such as unexpected file descriptor reuse, return values are checked for consistency and legality (e.g., only valid file descriptors are returned), and descriptors are recorded within enclave memory to maintain provenance.

The monitor enclave’s design prevents unmediated system calls from bi-enclaves, establishes centralized policy enforcement, and mitigates classic TEE–OS interaction attacks.

3. Hardware-Protected Inter-Enclave Memory Sharing

Stockade introduces a model for efficient, hardware-level sharing of protected memory between exactly two enclaves without software-based encryption.

• EPCM Extension: Each page’s EPCM entry acquires an optional coowner_eid field, enabling pairwise sharing:

$$\mathrm{EPCM}[P] = \{\mathrm{owner\_eid}, \mathrm{coowner\_eid}, \mathrm{VA}_{\mathrm{enclave}}\}$$

• New Instructions:
  • ESADD($P_\text{page}$, $EID_\text{coowner}$): The owner enclave requests sharing; hardware zeroes the page and marks it pending.
  • ESACCEPT($P_\text{page}$): Co-owner enclave accepts; stale TLBs are flushed, and both enclaves receive R/W/X permissions.
• Attestation Handshake: After ESACCEPT, both enclaves verify each other’s MRENCLAVE identity over the shared page. Access is revoked if attestation fails.
• Confidentiality & Integrity: The Memory Encryption Engine (MEE) continues to enforce encrypted and MAC-protected memory for all shared pages, guaranteeing that pairwise shared regions remain confidential and integrity-checked without extra cryptography.

This extension ensures that after sharing, only the owner and co-owner enclaves (i.e., $$\mathrm{Owners}(P) = \{\mathrm{owner\_eid}, \mathrm{coowner\_eid}\}$$) may access page $P$; all others are denied at the hardware level.

4. Security Properties and Threat Model

Stockade defines its own threat model, assuming a trusted CPU/microcode/PRM/MEE and monitor enclave code, while treating the OS and hypervisor as fully adversarial. The main protection goals are:

• Confinement: Hardware-level enforcement ensures that bi-enclaves can only access memory within their ELRANGE.
• Mediated System Calls: All system interactions are constrained by an attested policy within the monitor enclave.
• Secure Inter-Enclave Channel: Shared EPC memory allows communication without resorting to shared, untrusted memory or user-level cryptography.

Residual risks include microarchitectural side channels (cache, TLB, branch predictor), denial-of-service (OS can terminate enclaves), and potential for cross-module code-reuse attacks. Side-channel (e.g., Spectre, Foreshadow) and speculative execution are explicitly out of scope in the Stockade model.

5. Performance Evaluation and Impact

Stockade’s design was evaluated via an SGX simulation platform (Intel i7-7700, 64 GB RAM), benchmarking several security–performance tradeoffs:

Benchmark / Scenario	Baseline (SGX)	Software Sandboxing (SGXJail)	Stockade Neutral Monitor	HW-Only Isolation (Stockade)
End-to-End Syscall Sandbox (SQLite+YCSB)	$$\forall t: (\mathrm{mode}_t = \text{bi-enclave}) \implies (L_E \leq \mathrm{VA}_t < U_E)$$0	$$\forall t: (\mathrm{mode}_t = \text{bi-enclave}) \implies (L_E \leq \mathrm{VA}_t < U_E)$$1	$$\forall t: (\mathrm{mode}_t = \text{bi-enclave}) \implies (L_E \leq \mathrm{VA}_t < U_E)$$2	–
NBench Isolation (Chancel)	Native	$$\forall t: (\mathrm{mode}_t = \text{bi-enclave}) \implies (L_E \leq \mathrm{VA}_t < U_E)$$3 slowdown	$$\forall t: (\mathrm{mode}_t = \text{bi-enclave}) \implies (L_E \leq \mathrm{VA}_t < U_E)$$4 overhead	–
1KB Inter-Enclave Comm	–	SW-encrypt baseline	$$\forall t: (\mathrm{mode}_t = \text{bi-enclave}) \implies (L_E \leq \mathrm{VA}_t < U_E)$$5 baseline	–
64B Inter-Enclave Comm	–	SW-encrypt baseline	$$\forall t: (\mathrm{mode}_t = \text{bi-enclave}) \implies (L_E \leq \mathrm{VA}_t < U_E)$$6 baseline	–
FTPS+Accounting	–	–	$$\forall t: (\mathrm{mode}_t = \text{bi-enclave}) \implies (L_E \leq \mathrm{VA}_t < U_E)$$7 latency	–
SQL (multi-module query)	–	–	$$\forall t: (\mathrm{mode}_t = \text{bi-enclave}) \implies (L_E \leq \mathrm{VA}_t < U_E)$$8 faster than SGXJail	–
ML Inference Pipeline	–	–	$$\forall t: (\mathrm{mode}_t = \text{bi-enclave}) \implies (L_E \leq \mathrm{VA}_t < U_E)$$9 faster	–

Stockade delivers substantial improvements over software-only sandboxes (e.g., SGXJail), with 18.6%–19.5% speedup in multi-module scenarios, and virtually negligible overhead in single-module, hardware-isolation cases.

6. Hardware Modifications and Compatibility

Required extensions to Intel SGX for Stockade operation are minimal, primarily at the microcode and EPCM levels:

• SECS struct: Addition of a 1-bit "bi-enclave" flag, set upon EINIT.
• EPCM: 52-bit field for co-owner pointer.
• Instruction Set: New ESADD/ESACCEPT instructions for sharing; EEXIT blocks for bi-enclave mode.
• TLB Miss Handler: Enforcement of ELRANGE and owner/co-owner checks during address translation.

These changes do not impact existing SGX enclaves unless they opt in to bi-enclave or sharing features. No modifications to operating system code or unmodified SGX applications are necessary, preserving backward compatibility with pre-existing deployments.

7. Limitations and Research Directions

Stockade’s scope does not include mitigation of microarchitectural side channels (e.g., cache, TLB, speculative attacks), which remain an active area for integration with techniques such as T-SGX or dynamic software diversity. Other current limitations include:

• DoS by OS: The operating system can forcibly terminate or stall enclaves; hardware-assisted progress guarantees remain a potential future addition.
• Multi-Party Sharing: Presently restricted to pairwise sharing. Expansion to $t^{th}$0-party channels and group keys is a target for future work.
• Code-Reuse Attacks: No direct support for basic block randomization or CFI; incorporating lightweight control-flow integrity within enclaves is suggested.
• Dynamic Enclave Features: Improved dynamic memory management (e.g., on-demand paging, EPC expansion—SGX2) could increase operational flexibility.

These considerations delineate the boundaries of Stockade’s hardware sandbox guarantees and guide ongoing research toward enhanced side-channel, progress, and multi-party support.

---

Stockade provides a robust, hardware-enforced framework for distributed sandboxed applications, combining fine-grained bi-directional memory confinement, attested system call control, and pairwise secure memory sharing, with empirical overheads between 10%–50%—often outperforming software-only approaches (Park et al., 2021).