Modern systems mitigate Rowhammer using victim refresh, which refreshes neighbours of an aggressor row when it encounters a specified number of activations. Unfortunately, complex attack patterns like Half-Double break victim-refresh, rendering current systems vulnerable. Instead, recently proposed secure Rowhammer mitigations perform mitigative action on the aggressor rather than the victims. Such schemes employ mitigative actions such as row-migration or access-control and include AQUA, SRS, and Blockhammer. While these schemes incur only modest slowdowns at Rowhammer thresholds of few thousand, they incur prohibitive slowdowns (15%-600%) for lower thresholds that are likely in the near future. The goal of our paper is to make secure Rowhammer mitigations practical at such low thresholds.

The Rowhammer vulnerability is worsening, with the Rowhammer Threshold (TRH) reducing from 139K to 4.8K activations over the last decade. As thresholds reduce further, the number of possible aggressor rows increases inversely, making it difficult to reliably track such rows in a storage-efficient manner for typical Rowhammer defenses. To be secure at lower thresholds, academic trackers like Graphene must dedicate prohibitively high storage (hundreds of KBs to MBs) at the chip's design time. Recent in-DRAM trackers from the industry, such as DSAC-TRR, perform approximate tracking and sacrifice guaranteed protection for reduced storage overheads, leaving DRAM vulnerable to Rowhammer attacks. Ideally, we seek a configurable tracker that is secure and precise, incurs negligible dedicated storage and performance overheads, and scales at deployment to track arbitrarily low thresholds. To that end, we propose START - a Scalable Tracker for Any Rowhammer Threshold. Rather than relying on dedicated SRAM structures, START dynamically repurposes a small fraction of the Last-Level Cache (LLC) to store tracking metadata. START leverages the observation that while the memory contains millions of rows, typical workloads touch only a small subset of rows within a refresh period of 64ms. Thus, allocating tracking entries on demand reduces storage significantly. If the application does not access many rows in memory, START does not reserve any LLC capacity. Otherwise, START dynamically uses 1-way, 2-way, or 8-way of the cache set based on demand. START consumes, on average, 9.4% of the LLC capacity to store metadata, which is 5 × lower compared to dedicating a counter in LLC for each row in memory. We also propose START-M, a memory-mapped START for large-memory systems. Our designs require only 4KB SRAM for newly added structures and perform within 1% of idealized tracking even at TRHof less than 100.

DRAM cells are susceptible to Data-Disturbance Errors (DDE), which can be exploited by an attacker to compromise system security. Rowhammer is a well-known DDE vulnerability that occurs when a row is repeatedly activated. Rowhammer can be mitigated by tracking aggressor rows inside DRAM (in-DRAM) or at the Memory Controller (MC). Row-Press (RP) is a new DDE vulnerability that occurs when a row is kept open for a long time. RP significantly reduces the number of activations required to induce an error, thus breaking existing RH solutions. Prior work on Explicit Row-Press mitigation, ExPress, requires the memory controller to limit the maximum row-open-time, and redesign existing Rowhammer solutions with reduced Rowhammer threshold. Unfortunately, ExPress incurs significant performance and storage overheads, and being a memory controller-based solution, it is incompatible with in-DRAM trackers. In this paper, we propose Implicit Row-Press mitigation (in-Press), which does not restrict row-open-time, is compatible with memory controller-based and in-DRAM solutions and does not reduce the tolerated Rowhammer threshold. In-Press treats a row open for a specified time as equivalent to an activation. We design in-Press by developing a Unified Charge-Loss Model, which combines the net effect of both Rowhammer and Row-Press for arbitrary patterns. We analyze both controller-based (Graphene and PARA) and in-DRAM trackers (Mithril and MINT). We show that in-Press makes Rowhammer solutions resilient to Row-Press transparently without affecting the Rowhammer threshold.

The memory system is a major performance determinant for server processors. Ever-growing core counts and datasets demand higher memory bandwidth and capacity. DDR—the dominant processor interface to memory—requires a large number of on-chip pins, which is a scarce resource, thus limiting the processor’s memory bandwidth. With limited bandwidth, multiple concurrent memory requests experience significant queuing delays that often overshadow DRAM’s service time and degrade performance. We present CoaXial, a memory system design for throughput-oriented manycore servers that replaces all of the processor’s DDR interfaces with the pin-efficient CXL interface, which offers $4 \times$ higher bandwidth per pin. While such replacement incurs a considerable latency overhead, we demonstrate that, for many workloads, and with careful integration, CXL’s higher bandwidth more than offsets its latency premium. Our evaluation shows that CoaXial improves the performance of manycore throughput-oriented servers by $1.39 \times$ on average and by up to $3 \times$.

Page tables enforce process isolation in systems. Rowhammer attacks break process isolation by flipping bits in DRAM to tamper page tables and achieving privilege escalation. Moreover, new Rowhammer attacks break existing mitigations. We seek to protect systems against such breakthrough attacks. We present PT-Guard, an integrity protection mechanism for page tables. PT-Guard uses unused bits in Page Table Entries (PTE) to embed a Message Authentication Code (MAC) for the PTE cacheline without any storage overhead. These unused bits arise from PTEs supporting petabytes of physical memory while systems targeted by Rowhammer use at-most terabytes of mem-ory. By storing and verifying MACs for PTEs, PT-Guard detects arbitrary bit-flips in PTEs. Moreover, PT-Guard also provides best-effort correction of faulty-PTEs leveraging value locality. PT-Guard protects page tables from breakthrough Rowhammer attacks with negligible hardware changes, no DRAM storage, <72 bytes of SRAM, 1.3% slowdown, and no software changes.

Rowhammer allows an attacker to induce bit flips in a row by rapidly accessing neighboring rows. Rowhammer is a severe security threat as it can be used to escalate privilege or break confidentiality. Moreover, the threshold of activations needed to induce Rowhammer continues to reduce and new attacks like Half-Double break existing solutions that refresh victim rows. The recently proposed Randomized Row-Swap (RRS) scheme is resilient to Half-Double as it provides mitigation by swapping an aggressor row with a random row. However, to ensure security, the threshold for triggering a row-swap must be set much lower than the Rowhammer threshold, leading to a significant performance loss of 20% on average, at a Rowhammer threshold of 1K. Furthermore, the SRAM overhead for storing the indirection table of RRS becomes prohibitively large – 2.4MB per rank at a Rowhammer threshold of 1K. Our goal is to develop a scalable Rowhammer mitigation that incurs negligible performance and storage overheads.To this end, we propose AQUA, a Rowhammer mitigation that breaks the spatial correlation between aggressor and victim rows by dynamically quarantining the aggressor row in a dedicated region of memory. AQUA allows for an effective row migration threshold much higher than in RRS, leading to an order of magnitude less slowdown and SRAM. As the security of AQUA is not reliant on keeping the destination row a secret, we further reduce the SRAM overheads of the indirection table by storing it in DRAM, and accessing it on-demand. We derive the size of the quarantine region required to ensure security for AQUA and show that reserving about 1% of DRAM is sufficient to mitigate Rowhammer at a threshold of 1K. Our evaluations show that AQUA incurs an average slowdown of 2% and an SRAM overhead (for mapping and migration) of only 41KB per rank at a Rowhammer threshold of 1K.