Hardware-enforced fine-grained isolation of untrusted code

Abstract

We present a novel combination of hardware (architecture) and software (compiler) techniques to support the safe execution of untrusted code. While other efforts focus on isolating processes, our approach isolates code and data at a function (as in, C function) level, to enable fine-grained protection within a process as needed for downloaded plugins, libraries, and modifications of open-source projects. Our solution also enforces timing restrictions to detect denial of service from untrusted code, and supports protection of dynamically allocated memory. Because bookkeeping data can become substantial (permission tables that at their finest granularity describe which memory words may be accessed by which functions), our solution employs a stack-structured bookkeeping mechanism that tracks the flow of execution and automatically dispenses with bookkeeping data when no longer needed. This approach also enables an architectural optimization to handle permissions for dynamically allocated memory, allowing heap blocks to be appropriately shared across the trust boundary. Tested across a suite of benchmarks, our solution had a worst case 12% overhead and 3.5% average overhead at the finest level of code granularity (every single function in its own unit of isolation). The overhead is easily reduced by using trace-driven analysis to combine functions into coarser-grained groups that share permissions.

Hardware Containers for Software Components: A Trusted Platform for COTS-Based Systems

“…Three CAM accelerated tables maintain container context. The Container Identification Table lists [10][11][12][13][14][15][16][17][18][19][20] for critical operation speedup. The loading of the container permission state is accelerated by a dedicated permission cache, which helps reduce the fetch delays and limits the memory bus load.…”

“…Recent work on fast CAMs for range-checking has shown that the speed of the rangechecking is on par with regular CAM lookups, which can be achieved in a single cycle [22]. Further details of our architecture design and optimization techniques are addressed in a separate paper [14].…”

“…The results show moderate additional overhead with a 5.97% average across all benchmarks and a maximum of 24.74% for the CRC program, which has a very high function call frequency (2.75 function calls per 100 processor cycles). More detailed performance results can be found in [14].…”

“…For some of these features, we refine and integrate some ideas in the architecture literature (for example, the memory-protection mechanism in [33] and the notion of recursive recovery in [6]), and for others (denialof-service, memory-protection of dynamic memory), we devise entirely new solutions. The architectural details are explored further in a separate paper [14].…”

Automation for creating and configuring security manifests for hardware containers

“…Our prior work introduced hardware containers [3], [4] for fine-grained isolation of code and data that targets code written with a hierarchical control flow, which is normal in imperative, procedural, and object-oriented languages. Containers isolate code at the granularity of functions as a natural boundary for structured components and programs.…”