ZenHammer: Rowhammer attacks on AMD Zen-based platforms

Original Article ↗ Hacker News Discussion ↗

DDR5, On-Die ECC, and “Fragility” of Modern DRAM

  • Several comments note DDR5’s on-die ECC is required to make the technology reliable at its higher densities and speeds.
  • Some argue this isn’t a “negative” but part of a general trend: all storage becomes probabilistic and then corrected with math.
  • Others describe DDR5 as “fragile” because cell sizes and timing margins are pushed so hard that some bits would otherwise fail; ECC is used instead of backing off performance/density.
  • There’s debate whether DDR5 is “mostly fixed” for Rowhammer; the paper shows bit flips on at least one DDR5 device, but attacks were only successful on 1/10 tested DDR5 modules and need further research.

Rowhammer as a Physical Phenomenon and Threat Model

  • Rowhammer is framed as a DRAM physics problem: repeated accesses to one row cause charge leakage and bit flips in neighboring rows.
  • Smaller, denser, closer cells make attacks easier but also make RAM cheaper, faster, and more efficient.
  • Some say this is an “inevitable” outcome of industry-wide pressure for density and cost, not just “profit-maximizing negligence.”

Real-World Risk for Normal Users

  • Many argue average users are unlikely to be directly impacted; typical attacks against them are simpler software exploits and malware.
  • Others stress that Rowhammer and similar bugs have been demonstrated from JavaScript in browsers, in VMs, phones, and even over networks; the lack of observed mass exploitation doesn’t mean zero risk.
  • Script blocking (NoScript, uBlock, JS-by-default-off) is discussed as a practical mitigation, though some find it too inconvenient.

ECC as Mitigation

  • Strong consensus that ECC significantly raises the bar: many single/double flips become correctable or crash the system, converting a stealthy exploit into an obvious reliability problem.
  • Critics of “ECC doesn’t help” call that framing misleading; attack success then generally requires many machine halts or detectable error logs.
  • A key caveat: ECC reporting and handling vary by platform; some desktop/consumer platforms correct silently or don’t surface counters via IPMI, though OS-level Machine Check handling still exists in many setups.

AMD/Intel ECC and Platform Choices

  • Desktop AMD Ryzen has (now officially) ECC support, but whether it works depends on the motherboard. ASRock and ASUS are frequently cited as enabling it on AM5 boards.
  • Laptop ECC is largely limited to expensive “mobile workstations” and Pro SKUs; recent AMD mobile generations had shifting, unclear ECC support in public specs.
  • Unbuffered ECC DDR5 is significantly more expensive (often ~50–100% premium) and lacks factory overclock/XMP binning, so users may need manual tuning for performance.
  • Threadripper supports registered ECC and is seen as great but overkill (cost, core count, PCIe lanes) for many home users.

Memory Encryption and Other Defenses

  • Memory encryption (e.g., AMD SEV/Secure Memory Encryption) is said to prevent Rowhammer from turning into targeted data corruption; bit flips become random in ciphertext, likely causing crashes rather than controlled exploits.
  • This can make systems less “graceful” (single-bit flips causing fatal errors) but more obviously broken, which is viewed as preferable from a security perspective.

Broader Security and Privacy Context

  • Several comments contrast highly technical hardware attacks with the much larger, ongoing risks from pervasive tracking, data brokerage, and insecure IoT devices.
  • Some argue society needs broad privacy regulation more urgently than ever-more-marginal mitigations for exotic hardware bugs.