MemTracker: Efficient and Programmable Support for Memory Access Monitoring and Debugging

Abstract

Memory bugs are a broad class of bugs that is becoming increasingly common with increasing software complexity, and many of these bugs are also security vulnerabilities. Unfortunately, existing software and even hardware approaches for finding and identifying memory bugs have considerable performance overheads, target only a narrow class of bugs, are costly to implement, or use computational resources inefficiently.This paper describes MemTracker, a new hardware support mechanism that can be configured to perform different kinds of memory access monitoring tasks. MemTracker associates each word of data in memory with a few bits of state, and uses a programmable state transition table to react to different events that can affect this state. The number of state bits per word, the events to which MemTracker reacts, and the transition table are all fully programmable. MemTracker's rich set of states, events, and transitions can be used to implement different monitoring and debugging checkers with minimal performance overheads, even when frequent state updates are needed. To evaluate MemTracker, we map three different checkers onto it, as well as a checker that combines all three. For the most demanding (combined) checker, we observe performance overheads of only 2.7% on average and 4.8% worst-case on SPEC 2000 applications. Such low overheads allow continuous (always-on) use of MemTrackerenabled checkers even in production runs.

Flexible Hardware Acceleration for Instruction-Grain Lifeguards

“…3 Unfortunately, software-only instructiongrain lifeguards, which are mainly based on dynamic binary instrumentation (DBI), 4,5 typically slow down the monitored program by 10 to 100 times, 4 because lifeguard functionality is invoked on nearly every instruction. To address this overhead, researchers have proposed several hardware optimizations, each tailored to a specific class of lifeguards: for example, memory-access monitoring, [6][7] data-race detection, 8 and information-flow tracking with simple metadata. [9][10][11] However, each of these mechanisms is useful only for the narrow class of lifeguards that it supports.…”

Quantifying the Potential of Program Analysis Peripherals

“…Statistical methods [4] and anomaly detection techniques for finding memory errors [3] are two examples. Relevant to our work, HeapMon [31] uses helper threads while MemTracker [36] provides support for attaching state bits to each virtual memory location to detect heap errors. MemorIES [17] proposes using an FPGA for accelerating memory system design by capturing and analyzing memory traffic, while iWatcher [39] provides mechanisms to watch for unsafe pointer dereferences and memory regions.…”

Watchdog: Hardware for safe and secure manual memory management and full memory safety

“…Location-based approaches (e.g., [17,25,34]) use the location (address) of the object to determine whether it is allocated or not. An auxiliary data structure records the allocated/deallocated status of each location, and it is updated on memory allocations (e.g.…”

“…Although useful for mitigating some use-after-free exploits, such approaches fail to detect use-after-free errors on the stack and suffer from locality-destroying memory fragmentation. Other approaches seek to detect errors by tracking the allocation/deallocation status of regions of memory (via shadow space in software [26], with hardware [5,34], or page-granularity tracking via virtual memory mechanisms [10,20]). Alternative approaches track and check unique identifiers either completely with software [3,23,29,35] or with hardware acceleration [7].…”