# Are We Susceptible to Rowhammer? An End-to-End Methodology for Cloud Providers

arXiv: https://arxiv.org/abs/2003.04498 · HTML: https://mlsanity.com/paper/2003.04498/

## Key facts

- Cited by 4 papers in the map (data through 14 Oct 2026).
- First posted on arXiv 10 Mar 2020.

## Built on by (most cited first, 4 of 4)

- [A Step Toward World Models: A Survey on Robotic Manipulation](https://mlsanity.com/paper/2511.02097/) (2025)
- [Don't Knock! Rowhammer at the Backdoor of DNN Models](https://mlsanity.com/paper/2110.07683/) (2021)
- [Attacking Deep Learning AI Hardware with Universal Adversarial Perturbation](https://mlsanity.com/paper/2111.09488/) (2021)
- [Remote Rowhammer Attack using Adversarial Observations on Federated Learning Clients](https://mlsanity.com/paper/2505.06335/) (2025)

## Abstract (arXiv)

Cloud providers are concerned that Rowhammer poses a potentially critical threat to their servers, yet today they lack a systematic way to test whether the DRAM used in their servers is vulnerable to Rowhammer attacks. This paper presents an end-to-end methodology to determine if cloud servers are susceptible to these attacks. With our methodology, a cloud provider can construct worst-case testing conditions for DRAM. We apply our methodology to three classes of servers from a major cloud provider. Our findings show that none of the CPU instruction sequences used in prior work to mount Rowhammer attacks create worst-case DRAM testing conditions. To address this limitation, we develop an instruction sequence that leverages microarchitectural side-effects to ``hammer'' DRAM at a near-optimal rate on modern Intel Skylake and Cascade Lake platforms. We also design a DDR4 fault injector that can reverse engineer row adjacency for any DDR4 DIMM. When applied to our cloud provider's DIMMs, we find that DRAM rows do not always follow a linear map.