Preventing Rowhammer Exploits via Low-Cost Domain-Aware Memory Allocation

TL;DR

Citadel is a new memory allocator design that prevents Rowhammer-initiated security exploits by addressing the vulnerability's root cause: physical adjacency of DRAM rows.

Abstract

Rowhammer is a hardware security vulnerability at the heart of every system with modern DRAM-based memory. Despite its discovery a decade ago, comprehensive defenses remain elusive, while the probability of successful attacks grows with DRAM density. Hardware-based defenses have been ineffective, due to considerable cost, delays in commercial adoption, and attackers' repeated ability to circumvent them. Meanwhile, more flexible software-based solutions either incur substantial performance and memory capacity overheads, or offer limited forms of protection. Citadel is a new memory allocator design that prevents Rowhammer-initiated security exploits by addressing the vulnerability's root cause: physical adjacency of DRAM rows. Citadel enables creation of flexible security domains and isolates different domains in physically disjoint memory regions, guaranteeing security by design. On a server system, Citadel supports thousands of security domains at a modest 7.4% average memory overhead and no performance loss. In contrast, recent domain isolation schemes fail to support many workload scenarios due to excessive overheads, and incur 4--6x higher overheads for supported scenarios. As a software solution, Citadel offers readily deployable Rowhammer-aware isolation on legacy, current, and future systems.

Figures (10)

• Figure 1: (a) Row-sized chunks (left) waste memory capacity (67% loss with two guard rows); subarray-sized chunks (right) strand memory (33% in our evaluations) and limit the number of supported security domains. (b) In typical systems, the memory footprint of most processes is below a few megabytes, while most memory is occupied by few large-footprint processes.
• Figure 2: Modern memory mappings distribute lines belonging to a page to different banks of memory.
• Figure 3: Illustration of security domains and corresponding security zones in memory. Each zone comprises a contiguous range of global rows, with the first $N_G$ of them serving as guard rows. One guard row per zone ($N_G=1$) shown.
• Figure 4: Memory allocation and chunk reservation optimizations to minimize memory capacity overheads. $N_G=1$ and two DRAM banks shown for simplicity.
• Figure 5: Flowchart of memory allocation logic.