Hardware Support for Safety Interlocks and Introspection

Abstract

Hardware interlocks that enforce semantic invariants and allow fine-grained privilege separation can be built with reasonable costs given modern semiconductor technology. In the common error-free case, these mechanisms operate largely in parallel with the intended computation, monitoring the semantic intent of the computation on an operation-by-operation basis without sacrificing cycles to perform security checks. We specifically explore five mechanisms: (1) pointers with manifest bounds (fat pointers), (2) hardware types (atomic groups), (3) processor-supported authority, (4) authority-changing procedure calls (gates), and (5) programmable metadata validation and propagation (tags and dynamic tag management). These mechanisms allow the processor to continuously introspect on its operation, efficiently triggering software handlers on events that require logging, merit sophisticated inspection, or prompt adaptation. We present results from our prototype FPGA implementation of a processor that incorporates these mechanisms, quantifying the logic, memory, and latency requirements. We show that the dominant cost is the wider memory necessary to hold our metadata (the atomic groups and programmable tags), that the added logic resources make up less than 20% of the area of the processor, that the concurrent checks do not degrade processor cycle time, and that the tag cache is comparable to a small L1 data cache.

A verified information-flow architecture

“…More detailed descriptions can be found elsewhere [29,33,34,35,45,46,56,62]. SAFE's system software performs process scheduling, stream-based interprocess communication, storage allocation and garbage collection, and management of the low-level tagging hardware (the focus of this paper).…”

“…Proof-carrying code [12,13,38] and typed assembly language [61,94,95] have been used for enforcing IFC on low-level code without low-level analysis or adding the compiler to the TCB. In SAFE [29,34] we follow a different approach, enforcing noninterference using purely dynamic checks, for arbitrary binaries in a custom-designed instruction set. The mechanisms we use for this are similar to those found in recent work on purely dynamic IFC for high-level languages [1,4,5,6,7,40,41,44,45,63,72,75,78,83,86]; however, as far as we know, we are the first to push these ideas to the lowest level.…”

Micro-Policies: Formally Verified, Tag-Based Security Monitors

“…Micro-Policies The micro-policies framework and the PUMP architecture have their roots in SAFE, a clean-slate, securityoriented architecture [36], [40] and the earlier TIARA [75] and ARIES [20] designs. There, the PUMP was used only to implement dynamic IFC; other special-purpose hardware mechanisms enforced properties such as memory safety [55] and compartmentalization [40].…”

“…There, the PUMP was used only to implement dynamic IFC; other special-purpose hardware mechanisms enforced properties such as memory safety [55] and compartmentalization [40]. Still, the PUMP design in the SAFE system was made quite flexible, since dynamic IFC is an active area of research, with various mechanisms [14], [18], [19], [48], [50], [78] and "label models" [61], [77] being proposed regularly, making baked-into-hardware solutions unattractive.…”

SAFE: A clean-slate architecture for secure systems

“…A number of papers have appeared on several aspects of the SAFE project, such as the hardware interlocks [1], multi-level cache algorithms for tag management [2], and error handling in the presence of dynamic information flow control [3]. We presented a paper [4] at the 2011 Workshop on Programming Languages and Operating Systems (PLOS) describing our initial design goals.…”