Tuesday, March 26th 2024

AMD Response to "ZENHAMMER: Rowhammer Attacks on AMD Zen-Based Platforms"

On February 26, 2024, AMD received new research related to an industry-wide DRAM issue documented in "ZENHAMMER: Rowhammering Attacks on AMD Zen-based Platforms" from researchers at ETH Zurich. The research demonstrates performing Rowhammer attacks on DDR4 and DDR5 memory using AMD "Zen" platforms. Given the history around Rowhammer, the researchers do not consider these rowhammering attacks to be a new issue.

Mitigation
AMD continues to assess the researchers' claim of demonstrating Rowhammer bit flips on a DDR5 device for the first time. AMD will provide an update upon completion of its assessment.
AMD microprocessor products include memory controllers designed to meet industry-standard DDR specifications. Susceptibility to Rowhammer attacks varies based on the DRAM device, vendor, technology, and system settings. AMD recommends contacting your DRAM or system manufacturer to determine any susceptibility to this new variant of Rowhammer.
AMD also continues to recommend the following existing DRAM mitigations to Rowhammer-style attacks, including:
  • Using DRAM supporting Error Correcting Codes (ECC)
  • Using memory refresh rates above 1x
  • Disabling Memory Burst/Postponed Refresh
  • Using AMD CPUs with memory controllers that support a Maximum Activate Count (MAC) (DDR4)
    • 1st Gen AMD EPYC Processors formerly codenamed "Naples"
    • 2nd Gen AMD EPYC Processors formerly codenamed "Rome"
    • 3rd Gen AMD EPYC Processors formerly codenamed "Milan"
  • Using AMD CPUs with memory controllers that support Refresh Management (RFM) (DDR5)
    • 4th Gen AMD EPYC Processors formerly codenamed "Genoa"
Acknowledgement
AMD thanks ETH Zurich: Patrick Jattke, Max Wipfli, Flavien Solt, Michele Marazzi, Matej Boleskei, Kaveh Razavi for reporting their findings and engaging in coordinated vulnerability disclosure.
Source: AMD
Add your own comment

18 Comments on AMD Response to "ZENHAMMER: Rowhammer Attacks on AMD Zen-Based Platforms"

#1
Vayra86
For the... Memperor?
Posted on Reply
#2
user556
I suppose, given the vague insinuations, the question becomes: Is there any combination of manufacturers and settings that are completely immune? Or are they all just varying degrees of susceptibility? I'm guessing the latter, and that the problem will only be fully solved with redesigned cell/routing layout internal to the DRAMs.
Posted on Reply
#3
Easo
Vayra86For the... Memperor?
Suffer not the bitflippers to live!
Posted on Reply
#4
R-T-B
user556I suppose, given the vague insinuations, the question becomes: Is there any combination of manufacturers and settings that are completely immune?
It's been well known for some time all vendors are affected by ROWHAMMER attacks on DDR4 and earlier, but DDR5 was supposed to address this with it's internal ECC thing. I was skeptical at the time (since full DDR4 ECC didn't fix it either, how could a more limited approach?), and it seems that was warranted. It would not surprise me if this extends beyond AMD.

If you ask me, the industry has no answer short of a fundamental redesign and are basically telling people what a doctor tells you when you say "Doc, it hurts when I do this!"

"Well, then don't."

In other words, don't get infected with malware that might exploit this.
Posted on Reply
#5
JohH
Just use ECC.
Posted on Reply
#6
Chaitanya
JohHJust use ECC.
Even though AM4 unofficially supports ECC RAM not all vendors implement it or implement ECC RAM support correctly.
Posted on Reply
#7
user556
Rubbish, ECC was never intended to fix this. That was just pipe dreams from some hopeful laymen.
Posted on Reply
#8
JohH
user556Rubbish, ECC was never intended to fix this. That was just pipe dreams from some hopeful laymen.
Laymen? It's the first option AMD lists in this very article to avoid the problem.
Posted on Reply
#9
user556
Sure, ECC helps catch some potential bit flips. Everyone knows that. AMD are not saying ECC is a fix in any way at all.

This problem is much worse than exploits. It's a reliability issue for DRAM generally. It applies to all DRAM uses everywhere.

Either ECC needs beefed up massively on the presumption that normal operation generates bulk groups of errors, or the DRAM array construction needs an overhaul.
Posted on Reply
#10
JohH
And yet they say in the paper that they were not able to replicate Rowhammer data exploits on systems with ECC.
Posted on Reply
#11
user556
Quote: They also note that for the first time they've demonstrated bit flips on a DDR5 device, an AMD Zen 4 system (Ryzen 7 7700X). While their success was limited – only 1 in 10 DDR5 devices succumbed due to improvements like on-die error correction code (ECC), and a higher 32 ms refresh rate – they anticipate that their findings "will make it easier to port Rowhammer attacks to newer platforms in the future, such as DDR5 devices."

Regular ECC is not intended to defend against conditions that produces a barrage of bit flips. At the very least you're looking at crashes from the memory corruption.
Posted on Reply
#12
JohH
A halt is preferable and that's what you'll get from proper ECC. On chip ECC isn't ECC in the classical sense nor reporting errors.

In theory ECC isn't sufficient but no one is making a more resilient form of memory than that. It's the simplest solution with no demonstrated data exfil on DDR4 or DDR5 yet. And the other solutions listed after it provide even less protection.
Posted on Reply
#13
user556
There's no halt when the ECC fails to detect an error.
Yeah, ECC is the best we have right now, but it's not sufficient. ECC circuits are built to handle rare cases of single bit-flips, primarily from cosmic rays. Rowhammer is not actually an exploit problem but rather a reliability problem. DRAMs are, or have become, too fragile electrically. Probably the latter due to modern die shrinks.
Posted on Reply
#14
JohH
Use ECC and set it to halt on machine check exception, done. That's the best protection against rowhammer you get.

Screaming at JEDEC might make DDR6/7 different but does nothing to help current machines.
Posted on Reply
#15
user556
It's not a JEDEC issue either. It's more a fundamental cell structure and silicon routing issue. It's a property of the fine grain nature of the process node. My guess is upcoming node shrinks will make it even worse.
Posted on Reply
#16
JohH
The zenhammer author references other papers which suggest it can be solved by different design of memory devices even at small nodes. If these are accurate, then it would be an issue of JEDEC priorities.
Posted on Reply
#17
user556
That depends on what he meant by design ... if he's talking about the structure of the bulk DRAM array then that's got very little to do with JEDEC.

There is a similarity to Flash memory trade-offs. Where long term reliability, and endurance, and speed are all properties of the number levels per cell. The effect is density is traded for performance. We might be seeing something similar emerging with DRAM. The highest densities will get relegated to low-grade consumer use.
Posted on Reply
#18
R-T-B
JohHJust use ECC.
ECC has historically been vulnerable to Rowhammer as well.
JohHAnd yet they say in the paper that they were not able to replicate Rowhammer data exploits on systems with ECC.
Old rowhammer was applicable on DDR4 ECC so I'm doubtful that this will be true forever with DDR5.

www.vusec.net/projects/eccploit/
Posted on Reply
Add your own comment
Nov 21st, 2024 11:38 EST change timezone

New Forum Posts

Popular Reviews

Controversial News Posts