Hacker News Reader

Comment by HankB99 | Hacker News Reader

I thought that Rowhammer was a thing of the past. Out of curiosity I found code to test for this and ran it on some of my hosts. My old desktop - I7-4770K/DDR3 - was susceptible. My old server - Xeon X3460/DDR3+ECC - was not. I upgraded the desktop with components based on a Ryzen 7 7700X/DDR5. It tested not susceptible. I'm not sure if that's a result of RAM designed not to be susceptible or that (I think) DDR5 RAM uses modules with on die ECC.

I was not able to test any of my Raspberry Pis because the test code used some facility available on the AMD64 architecture that is not available on the ARM64 processors. The newer Pi 4B and 5 use modules with on die ECC.

It seems to me that ECC should prevent Rowhammer susceptibility. That should prevent it on server grade H/W for anything still in service and newer consumer systems.

I have no idea if Rowhammer affects other architectures than AMD64.

View on HN

RowHammer is not a thing of the past. In fact, modern DRAM chips are significantly more susceptible to RowHammer due to their increased chip density [1].

[1] https://arxiv.org/abs/2005.13121

Thanks for the link. I guess I thought wrong. But I have more questions.

> with RowHammer protection mechanisms disabled

I wonder what this means. Is it S/W mitigations or does it include H/W factors like disabling on-die ECC.

It makes sense to me that with all other things being equal that higher density would lead to more susceptibility to Rowhammer. But as always, other things are not equal. I expect that on-die ECC would reduce susceptibility to Rowhammer and AFAIK that is used for DDR4 and DDR5 RAM, but perhaps not exclusively. Or did disabling "protection mechanisms" include disabling that (if it is even possible.)

The mitigations are usually about limiting the number of times you can access without refreshing. ECC helps in detecting and correcting (obviously) but it doesn't solve the underlying issue that accessing a cell over and over can cause bit flips in neighbors. ECC can be defeated if uncorrectable errors are not fatal or if the attacker can just crash the system over and over. Being able to introduce memory errors is a fundamental and unmitigatable issue that must be resolved by making these errors impossible. This isn't a problem software can solve.

In the "countermeasures" section of the linked paper[1], it mentioned that there are some new techniques available, but repeatedly mentioned that they are not yet available in consumer systems. Maybe rowhammer will eventually be a thing of the past despite the increasing chip density.

[1] https://arxiv.org/abs/2309.02545

Rowhammer is not architecture specific, since it's the DRAM rather than the CPU.

The paper linked in the patch references other works showing every defence at rowhammer can be bypassed somehow (I've not followed them all) - e.g. it specifically says that ECC and the like can be bypassed.

Interesting. I did not expect that Rowhammer was architecture specific, only that the test I found was.

I also did not expect that the various defenses, including ECC, could be bypassed.

It cannot be completely bypassed.

The attacker cannot control precisely which bits will be erroneous. When much more than 2 bits become erroneous, in a small fraction of the cases no error will be detected but a wrong value will be read at the next access.

However, in the majority of the cases an error will be detected, either non-correctable, or correctable in which case the corrected value will be wrong.

Despite the fact that wrong corrections are possible, in a system with ECC that is configured correctly it should be impossible for a RowHammer attack to escape detection, unlike for a system without ECC memory.

On a computer that is not defective, memory errors happen very seldom, typically one error after many months. Even only 2 correctable errors that happen in the same day represent an event that can be explained only by either a RowHammer attack or by a memory module that has become defective.

Therefore, a well configured computer with ECC memory should alert immediately its administrator when 2 on more errors happen in the same day, even if they had been correctable errors, because this requires immediate action, either stopping a RowHammer attack or replacing the defective memory module.

It would be pretty much impossible for any RowHammer attack to attain its target without triggering 2 or more ECC errors, which will reveal the attack attempt.

Only when there is no ECC the attack can proceed undetected for a time long enough to be successful.

Shouldn't an ECC non-correctable error trigger an immediate shutdown, because bad data could be committed to disk? (I guess unsafe shutdown could cause corruption elsewhere, but that seems like a reasonable risk) If attacks are a serious threat, then it would seem any alert that doesn't trigger immediate action would be risky (i.e. the attacker just erases alerts from logs).

LPDDR4 and above are supposed to have a feature to detect too many accesses to the same few rows and initiate a refresh cycle. Implementation quality may vary.

Have you ever seen any even moderately detailed specification of what the DRAM manufacturers do in this regard? I have not, and I looked. I am deeply sceptical ....

I don't believe that Rowhammer mitigations happen inside the DRAM chips themselves, I think that they are being put into the memory controller that talks to DRAM. Since DRAMs with built-in Rowhammer defences would have to spend transistors on this defence, those transistors would be 'wasted' in situations where Rowhammer is not part of the attacker model.

It makes sense to put it in the DRAM controller for many reasons. One is that the DRAM silicon process is optimized for memory but terrible for logic. Also, a DRAM bank is several chips in parallel to get the data bus width, and they would all have to duplicate the logic.

The disadvantage is that the controller and memory are made by different companies, so standards are required to agree on what access patterns are acceptable.

Agree. The extreme secrecy of DRAM manufacturers about the innards of their chips puts an additional obstacles in the way of memory controllers (MCs) implementing efficient Rowhammer defences. In particular, if the MC doesn't know which addresses are corresponding to neighbouring rows, how can an MC know with certainty that any concrete row is being attacked? (And, to the best of my knowledge, DRAM manufacturers don't give away this information.)

It might be good enough to detect a large number of accesses to any single row and then initiate a complete refresh. This wouldn't be triggered often by normal software. Most exploits have to use cache flush instructions, and with modern several-way-associative caches it would be rare for normal code to trigger it accidentally. In that case, the DRAM maker just has to specify the maximum number of accesses to any row.

It has been possible to re-purpose such additional refresh cycles as an additional Rowhammer attack vector, see https://www.usenix.org/conference/usenixsecurity22/presentat...

So on RAM that needed 18,000 distance-1 accesses, they were able to mount an effective attack with 300,000 distance-2 accesses and 5000 distance-1 accesses.

That's not a particularly big assist, and doesn't sound hard to mitigate.

If TRR pushed the rows it refreshes 10% closer to triggering their own TRR, then those 300,000 accesses would have triggered multiple refreshes in the target row.

My understanding from some previous papers was that many chips put in a small hash table to count accesses, and this table could be worked around.

It's easy enough to deal with if they stop cheaping out. Each row is so wide. A 10 bit counter to trigger neighbor refreshes would barely take any space.

Are you running the Ryzen DDR5 at stock speeds (4800 MT/s) or at some XMP profile.

Everything is at stock speed.

Reply on news.ycombinator.com